[vox] Mounting a Shared Win2k Drive for Students--no write access?

[Karsten M. Self]

on Wed, Mar 02, 2005 at 03:46:42PM -0800, Steve Hargadon (steve.hargadon at gmail.com) wrote:
> > You can't chmod mountpoint permissions where the underlying FS doesn't
> > support permissions.  man mount and read the umask/fmask uid/gid options
> > for your filesystem.
> 
> OK, I understand.
> 
> > 
> > The underlying filesystem is (mostly) orthogonal to use of SMB/CIFS.
> > The networking protocol handles the underlying file permissions.  RTFM
> > for particulars, as filesystems which have *no* u/g/w symantics present
> > their own special curves.
> > 
> 
> This I cannot understand.  I must go back into my cave and continue my
> studies...

u/g/w:  user, group, world.

  - user permissions apply to the owner of a file or directory.
  - group permissions apply to the group owner of a file or directory.
  - world permissions apply to _all_ users on the system.

This is reflected in the GNU/Linux permission string, where 'r' is read,
'w' is write, and 'x' is execute (there's a few other bits to worry
about, 'man chmod' for more info):

  - rwx rwx rwx
    `+' `+' `+'
     |   |   |
     |   |   +-- World permissions
     |   +-- Group permissions
     +-- Owner permissions


E.g.:  DOS's FAT filesystem allows specifing permissions (read, write)
and attributes (system, hidden), but *not* ownership.  DOS doesn't have
the concept of system users, and FAT doesn't support file ownership.

Samba, serving a share based on FAT, has to punt, then.  You're left
with the situation you're describing here:  hard-assignment of
permissions to u/g/w through your mount command.


More usually, you'll offer shares to specific users, and _that_ user
will have write permission to the share, but not other users (who may or
may not have access at all).  E.g.:  a typical GNU/Linux Samba server
configuration employs GNU/Linux users each with their own home
directory, which then is served as the Samba share for that user.


Getting back to my previous post, the *first* rule of GNU/Linux
filesystme security is that you pretty much *never* allow world-write
access to a file.  Too many bad things can happen, particularly where a
user writes a file and then trusts it to contain sane content.  As a
consequence, the _safe_ way to provide shared access to a filesystem
that _doesn't_ have ownership symantics is to create a role group (a
group associated with a specific role on your system), add selected
users to that group, and then mount the device with r/w access for
_that_ group.

Example from my system for floppy mounts (/etc/fstab):

------------------------------------------------------------------------
/dev/sda    /mnt/floppy vfat  user,gid=floppy,umask=0007          0    0
------------------------------------------------------------------------

...which is:  Mount the floppy (/dev/sda -- it's a USB external drive)
as /mnt/floppy, vfat format, with effective group ID 'floppy', umask
0007 (r/w/x for user and group, *no* permissons for world).

Why all this paranoia about world permissions?  Because you've got an
inherhently multiuser system, and may well be running processes which
allow external inputs.  Should someone find a remote exploit and get an
unprivileged (non-root) shell on your system, they still can't read your
files, because they don't have permission to do so.


Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    There's been too much gaming of the system until it is broke.  Capitalism
    is not working! There has been a corrupting of the system of capitalism.
    - Alan Greenspan, Federal Reserve Chairman, 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox/attachments/20050303/07c313af/attachment.bin