[ale] Permission hell question
Greg
runman at speedfactory.net
Wed Jun 30 20:36:26 EDT 2004
Why not use sudo and give your "everyday" user the abilities to
mount/unmount/whatever you need ?
Greg
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org]On Behalf Of Dow
> Hurst
> Sent: Wednesday, June 30, 2004 3:45 PM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] Permission hell question
>
>
> 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. *
> ************************************************************
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
>
More information about the Ale
mailing list