For example, how does mount decide if the current user has permissions to mount a filesystem? From what I know, it checks the fstab file and the group the user belongs to (I think plugdev, at least on Ubuntu).
Are those settings hard-coded into the program, or where does it get them? For example, say I wanted to give users in another group the ability to mount a filesystem, how does one do that?
EDIT: I'm looking for a general description of how security works. mount is just an example. I know more or less how filesystem permissions work, but clearly there's something else going on. I'm specially interested in knowing if there's a standard way in which programs implement security or if each does it differently.
According to the man page, there are some options you can put in
fstab
to control who gets to mount filesystems: "owner
" to let only the owner of the block device mount it, "group
" to let anyone in the device's group mount it, or "user
" or "users
" to let any ordinary user do it. The default if none of these are specified is that onlyroot
can mount the filesystem. Of course, whichever user performs the mount will need to have execute permission to themount
program itself.In your case, I suppose you could change the group of the block device to whatever group you wanted to be able to mount it and add "
group
" into the mount options infstab
. This only lets you specify one group that is able to mount the filesystem, though, so if you do this, people inplugdev
will probably lose the ability to perform the mount (unless they are also in the other group).Also, I'm not sure all those options exist on all systems. You should check
man mount(8)
on your own system before doing any of this.The security mechanism is completely down to permissions on files and programs such as nfsd that run as root (overriding file permissions) and maintain their own security mechanisms. Permissions on the block device files determine whether a user can mount that device. Every file has three sets of permissions (read, write, execute) for three classes of users (owner, group, world), plus a handful of special bits discussed below.
In the 'everything is a file` unix tradition the raw devices and exported volumes appear as special files with file system permissions. Remote mounting remote volumes is a little more complex and is discussed below.
If the user is logged in as the same uid as the owner of the file, then
owner
permissions can be used. Each user has a default group, and can be added to group entries in the/etc/group
file. When a user has access to a group the file permissions for the group are used. Otherwise the user has 'world` permissions. ACL's (Access Control Lists) can be used to grant permissions to specific users where they are available.Programs can override user level security by having the
setuid
bit set on their inode entry. This runs the program with the privileges of the owner of the binary rather than the privileges of the logged in user. Examples of such programs arenfsd
,mount
andsudo
. These programs have their own security mechanisms; for examplesudo
has/etc/sudoers
that is used to govern permissions.mount
andnfsd
work based on uid and gid, which must be in sync on both machines (often traditionally done via NIS). nfsd has a file called/etc/exports
which has the exported file systems and some permissions data. mount and its nfs drivers present credentials which nfsd uses to authenticate the user's right to mount the volume. On a local volume mount uses the file permissions of the block device.