[ale] Permission hell question

Dow Hurst dhurst at kennesaw.edu
Wed Jun 30 15:40:06 EDT 2004


I'm glad your setting the record straight on this but I think it may be 
distribution specific or device type specific.  I have had on my RH9 box the 
user option in /etc/fstab and also the device to have write permissions for 
all but could not write to a CF card thru a card reader once mounted.  Once I 
did it as root then the write worked.  It may be that RH9 on this box has 
another security setting preventing it and/or the USB card reader might not be 
interpreted the same way as a zip since different code is mounting it. 
Anyway, my thought is that the safest way to guarantee the method to work is 
to just su to root to mount and copy the files, especially for new users.  I 
may be quoting also too much IRIX specific NFS mount rules.  The underlying 
mount point permissions should play into what a mounted filesystem is capable 
of, so if not, then Linux is different than IRIX there.  Sorry for the wrong 
info!  I get different scenarios for success between RH and SuSE and IRIX for 
all this stuff.  The only way I can guarantee that a mount and write will work 
will be to do it all as root.  I don't like it and it is probably more a 
mixture of security settings, permissions, and the /etc/fstab options than 
anything else between distros that botches things up.  In SuSE on login you 
can get permissions on devices changed on the fly to the UID logging in.  On 
RH that doesn't seem to happen.  IRIX had it's own daemon, mediad, to manage 
removeable media.
Dow


Geoffrey wrote:
> 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.
> 

-- 
__________________________________________________________
Dow Hurst                  Office: 770-499-3428            *
Systems Support Specialist    Fax: 770-423-6744            *
1000 Chastain Rd. Bldg. 12                                 *
Chemistry Department SC428  Email:   dhurst at kennesaw.edu   *
Kennesaw State University         Dow.Hurst at mindspring.com *
Kennesaw, GA 30144                                         *
************************************************************
This message (including any attachments) contains          *
confidential information intended for a specific individual*
and purpose, and is protected by law.  If you are not the  *
intended recipient, you should delete this message and are *
hereby notified that any disclosure, copying, distribution *
of this message, or the taking of any action based on it,  *
is strictly prohibited.                                    *
************************************************************



More information about the Ale mailing list