[ale] Permission hell question

[Geoffrey]

Dow Hurst wrote:
> I was reading thru all the posts on this and you have basically a couple 
> of problems working together.
> 
> Vfat doesn't have permissions like normal Linux filesystems.  So you 
> can't change the permissions on files from the vfat default of anyone 
> reading and writing any files.
> 
> Your device file permissions were initially set so only root could 
> access the device.  That way your normal user id wouldn't be able to 
> write to the drive.
> 
> So, if you have to use the zip as a transfer between Win/DOS and Linux, 
> then you should keep the filesystem as is, and just leave your device 
> file that represents the zip drive as writeable for root.  Su to root to 
> mount, transfer files, and unmount the zip.

You really don't have to do this.  I mount my memory stick which has 
vfat fs by any user.  Relevant entry in /etc/fstab:

/dev/sda1 /mnt/memstick vfat noauto,user,exec 0 0

The 'user' option permits any user to mount the file system.

Once it's mounted, I can create files as well as directories on 
/mnt/memstick as the user who mounted the filesystem.

> If you move to the new 2.6 kernel then all the mount and umount stuff 
> goes away for removeable devices.  Plus, with permissions on the devices 
> set correctly by the kernel for removeable devices you can work as a 
> user.  I need to read up on that last statement but SuSE 9.1 was a dream 
> for the use of CD's and floppies when I was trying it out.
> 
> Using mtools is a nice idea since it is designed to work with vfat.  The 
> unix cp -p command won't work like you'd expect since you don't have 
> ownership or permissions per se under vfat.  I believe the kernel just 
> calls all the files and directories as owned by root unless you have it 
> mounted as nobody.

Not exactly.  If you can create a file on the mounted file system, it is 
created as owned by the user who created it:

rhws/mnt/memstick> ls -lart
total 52
-r-xr-xr-x    1 esoteric users           0 Jul 16  2003 memstick.ind
drwxr-xr-x    6 root     root         4096 Jun 29 07:45 ..
drwxr-xr-x    2 esoteric users       16384 Jun 30 13:48 foo
drwxr-xr-x    4 esoteric users       16384 Jun 30 13:48 .

> The underlying mount point permissions are very important to match up 
> with what your filesystem has that will be mounted.  You can't see those 
> permissions on the mount point unless the filesystem isn't mounted yet 
> on that mount point.

This isn't accurate either, sorry Dow. :)

/mnt/memstick on my box was 755 and I can mount it and created/delete 
files or directories.  As root, I changed the perms of /mnt/memstick to 
700.  I'm still able to mount the filesystem as well as create/delete 
files and directories.

Note the following:

root at rhws/home/esoteric> ls -ld /mnt/memstick
drwx------    2 root     root         4096 May 12 13:59 /mnt/memstick
root at rhws/home/esoteric> exit
exit
rhws/home/esoteric> mount /mnt/memstick
rhws/home/esoteric> ls -ld /mnt/memstick
drwxr-xr-x    3 esoteric users       16384 Dec 31  1969 /mnt/memstick

> This bites people using NFS, such as me, when you 
> have the mount point with 0700 permissions but expect to have 0755 on 
> the mounted filesystem.  The mounted filesystem's permissions hide and 
> overlay the underlying mount point's permissions when mounted so you'd 
> have to unmount to check and see what the values were.

I've not tried this for NFS, so I'm not sure what happens there.

-- 
Until later, Geoffrey                     Registered Linux User #108567
Building secure systems in spite of Microsoft