Re: [gentoo-user] k3b access rights

[Holly Bostick]

Michael Kintzios schreef:
<snip>
>> Second, for general use (video viewing, game playing, etc) what you
>>  most likely want is the "users" (note the "s" at the end) option,
>> which allows any user to mount/unmount the drive, as opposed to
>> just one:
>>
>> from man mount:
>>
>> user   Allow  an  ordinary  user  to mount the file system.  The
>> name of the mounting user is written to mtab so that he can unmount
>>  the file system again.  This option implies the options  noexec,
>> nosuid,  and  nodev (unless overridden by subsequent options, as in
>>  the option line user,exec,dev,suid).
>>
>> users  Allow  every  user to mount and unmount the file system.
>> This option implies the options noexec, nosuid, and nodev (unless
>> overridden by subsequent options, as in the option line
>> users,exec,dev,suid).
>
>
> So if I want a single user at-a-time to be able to mount the DVD
> drives I just enter user?  From memory I think I had concluded that
> adding the uid was necessary for CDROMS and NTFS/VFAT fs partitions,
> otherwise it was asking for fs type, or was coming up with "only root
> can do that" type of errors.  Need to try this again and make some
> notes.
>
> The problems that I have are probably two-fold.  The generic one is
> that I am not sure I have the correct mount options in /etc/fstab and
>  that I created the /mnt/cdrw, /mnt/cdrom1 etc. mountpoints with the
> correct access rights.  What are the default mount options and
> /mnt/mountpoints access rights for DVD writer and DVDROM?  Ditto for
> NTFS?

Sorry, I don't use NTFS, and I only have one user (me)-- and I don't use
/mnt/cdrom or /mnt/cdrw (or /mnt/ anything other than the self-created
/mnt/iso for mounting loopback images)-- my DVD is mounted to
/media/(cdrecorder) by udev (afaik it's udev that does it).

I take it you don't use udev? Or are you just under the impression that
you have to have /mnt/something (I had this problem for the first bit
after I switched)? In general use, /mnt./blah is kinda deprecated.

However, I do know that enabling writing to NTFS partitions in the
kernel is not recommended, unless you meet very specific criteria (as
the kernel driver can only overwrite a file of the exact same size to
such a partition, making editing pre-existing files pretty much
impossible; no idea about creating a new file).

UID/GID is (kinda) necessary for VFAT partitions, only to deal with the
possible ownership issues; if you specify the UID/GID of the expected
owner, that UID/GID can/will have write privileges to the partition
(automatically if UID, when specified if GID), which is useful for
shared partitions across multiple distros or OSes and sometimes for
multiple users on the same OS. But you may not need any given partition
to have write privileges. If, for example, the partition is only full of
music files that only need read privileges to play, which you'll almost
always have when mounting a partition. But if you wanted to
edit the ID2/3 tags of the music files, you would need write privileges.
But how many users on your system are actually likely to be editing such
tags-- given that said users could also destroy said files with a
Windows virus if the virus targeted MP3s and the user had write
privileges to the partition containing them? As the admin, you are
responsible for knowing what accesses your users actually need, and
balancing that against the dangers of giving them such access.

It really depends on what your specific setup needs, which we cannot know.

>
> The specific one is that I tried to delete a folder from a
> re-writable CD: a)while I was browsing it in konqueror and b)using
> k3b, but it couldn't do it.  I'll try again when I get home to see if
>  it behaves as expected after I ensure that it has not been mounted.

Um, hello, this is not WindowsXP. We do not packet-write (that means
treat a CD as if it was a floppy and write to it directly from the file
manager). You can (kinda) do this, if your kernel is set up to enable
packet-writing, but honestly that functionality is quite unstable and I
wouldn't use it even if I did like packet writing (which I do not and
never have in the some 6 to 7 years since it was introduced).

Basically what would need to happen in the real (Linux) world, without
packet writing, is that a CD burning program would have to create a temp
ISO of the files on the CDRW (which afaik it would have to be) without
the folder that you intended to delete, erase the current contents of
the CDRW and then rewrite the CDRW with the new ISO (which would
essentially delete the folder). But I could be wrong, as I don't use -RW
media anymore (and this is one of the reasons why).

In any case, I'm not completely sure that your expectations are
reasonable for the environment. Certainly expecting Konq to delete a
folder on a CD is unlikely to happen (because the device must be
mounted for Konq to see it, and the device is not going to be mounted
read-write under any circumstances; this is why, afaik, the kernel only
marks
the device as writeable using the ide-cd driver and then CD burning
programs use raw device access to access and write to it). I have no
idea whether Konq supports packet writing if enabled in the kernel, but
I would seriously doubt that it does.

K3b would likely do the whole "create a temp ISO without the
proposed-to-delete folder, erase, and reburn" thing, but it's possible
that you don't have K3b properly set up to do this (do you have a
location set for the creation of temporary ISO files, for example? Is
there enough space there for the temp file?). As I said, this is not
something I do, not using -RW media, but as far as I can see it's a
whole process. What errors precisely are you getting, so we could see
where in the process it may be failing?

HTH,
Holly

-- 
gentoo-user@g.o mailing list