# file permissions

## r.stiltskin

How can I enable an ordinary user to mount, umount, read and write filesystems in /mnt/... ?

As it is, only root can mount, unmount, and open files in memory sticks, usb drives, and FAT partitions.  I have tried chmod to change the permissions, but that is ignored.  I chown'ed /mnt/memstk to an ordinary user, but still only root could mount a device there and after mounting the owner and group changed back to root root, and only root can open the files.

And where are permissions, users, groups, etc, explained in Gentoo documentation?  What determines which groups can do what, and what determines the permissions of newly created groups?

----------

## carl.anderson

You might want to consider installing sudo.  Sudo allows you to define custom rules for users.

```
emerge sudo

man sudo
```

----------

## truc

 *carl.anderson wrote:*   

> You might want to consider installing sudo.  Sudo allows you to define custom rules for users.
> 
> ```
> emerge sudo
> 
> ...

 

Naa.. You should do it this way instead:

 */etc/fstab wrote:*   

> # <fs>                  <mountpoint>    <type>          <opts>              <dump/pass>
> 
> /dev/hdc                /mnt/cdrom      iso9660         noauto,ro,user           0 0

 

Add user if you want simple user to mount/umount your device (e.g. cdrom)

Add users if you want simple user to mount/umount your device (e.g. cdrom) and you want to offer the possiblity to an other user to umount it

Hope this help

----------

## r.stiltskin

Thanks guys but those are both workarounds & not the "real" answer.

I'd like to find out the details of how these permissions are set up in Gentoo.  It's obviously distro-specific, so I imagine there must be some documentation somewhere.  But where?

(i.e. I should be able to specify which users/groups can OPEN which directories, etc...)

----------

## truc

 *r.stiltskin wrote:*   

> Thanks guys but those are both workarounds & not the "real" answer.
> 
> I'd like to find out the details of how these permissions are set up in Gentoo.  It's obviously distro-specific, so I imagine there must be some documentation somewhere.  But where?
> 
> 

 

no, it's far from a work around, and it isn't gentoo specific...

 *Quote:*   

> (i.e. I should be able to specify which users/groups can OPEN which directories, etc...)

 

Yes you can, and man mount is your friend (may be a little bit of man fstab, but it's very short...)

 *man mount wrote:*   

>  For more details, see fstab(5).  Only the user that mounted a filesystem can unmount it again.  If any user should be able to unmount, then use users instead of user in the fstab line.   The  owner  option is similar to the user option, with the restriction that the user must be the owner of the special file. This may be useful e.g. for /dev/fd if a login script makes the console user owner of this device.  The group option is similar, with the restriction that the user must be member of the group of the special file.
> 
> (...)
> 
> (...)
> ...

 

Ok now?  :Smile: 

----------

## r.stiltskin

Found part of the answer here:

http://gentoo-wiki.com/MAN_mount_8#lbAN

so this allows a particular user to access the files

mount -o uid=[USERNAME],gid=[GROUPNAME] /dev/[DEVICE] /mnt/[MOUNTPOINT]

and I guess a similar line could be put in fstab to set one up for repeated use.

But I still don't see where/how group permissions are assigned to devices, ie the "audio" group, etc.  And how do they set up the "wheel" group to be able to run "su", since the ownership of /bin/su is root,root?  Presumably, there should be a way to allow the wheel group (or some new group) to run mount and umount.

(By gentoo-specific, I was referring to HOW the permissions are configured in Gentoo.  For example, I haven't seen anything like this "wheel" group in other distros I've used.  In RH9, Mandrake, Debian, any user can run su, for example.)

----------

## truc

OK, for security reason, when root create a new user, he doesn't belong to the wheel group, neither audio video.. and so on.. it gives more control over every user..But you can change this default behaviour...

useradd -D will show you the default value, for example my default is:

```
# useradd -D

GROUP=100

HOME=/home

INACTIVE=-1

EXPIRE=

SHELL=/bin/bash

SKEL=/etc/skel

CREATE_MAIL_SPOOL=no

```

(cf [b]man useradd for more details!)

This mean, when root creates a user, this user belongs to the group, which has gid=100, 

```
# grep 100 /etc/group

users:x:100:games,truc
```

So as u can see newly created user belongs only to the user group, you can change this behaviour(as I already said...) 

to add a user (r.stiltskin) to a group(wheel), (see man gpasswd)

```
# gpasswd -a r.stiltskin wheel
```

that's all  :Wink: 

ByeLast edited by truc on Fri Dec 09, 2005 7:47 am; edited 1 time in total

----------

## r.stiltskin

Thanks, but that's not the question.

The question is, how did they create the wheel group?  Or to put it another way, how did they set it up so that only members of the wheel group can use su?

 I know how to add users to the group, if the group already exists.

But suppose I want to create a new group, the 'mounties' group, of users who are allowed to use mount (but not any other powers of root).  How is that done?

----------

## truc

A work around can be:

```
# groupadd mounties

# useradd r.stiltskin -m -g mounties 

or even

# useradd r.stiltskin -m -G mounties
```

Then play with the group option in fstab, I 've never tried it but  may be something like this:

if the gid of mounties is 325

```
/dev/hdc /mnt/cdrom iso9660 noauto,ro,gid=325 0 0
```

I'm not sure ...

But if what you want is to allow the group mounties without to change anything in fstab. hum, I still don't know.. that's an interesting question, I guess  it's doable.. I will try to find something, but let me know if you find  :Smile: 

[EDIT]:

I was thinking about that, and I think it's now a good time of using sudo:

I still don't try it (I think it should work):

```
 # visudo

```

add the line:

```

%mounties  ALL = NOPASSWD: /bin/mount

%mounties  ALL = NOPASSWD: /bin/umount
```

Is it what you want?

[/EDIT]

----------

## kadeux

r.stiltskin wrote:

 *Quote:*   

> I haven't seen anything like this "wheel" group in other distros I've used. In RH9, Mandrake, Debian, any user can run su, for example.

 

You can set up any distro that is using PAM (Pluggable Authentication Modules) to restrict the access to the su command with   pam_wheel.so, which uses the wheel group by default. It is *not* gentoo specific!

r.stiltskin wrote:

 *Quote:*   

> ... how did they set it up so that only members of the wheel group can use su? 

 

Looking at the PAM configuration file for su (/etc/pam.d/su), you can see the following line if you have not edit the default setup:

```
auth required pam_wheel.so use_uid
```

If you are using pam-0.78-r3, the options are explained in /usr/share/doc/pam-0.78-r3/modules/README.pam_wheel.gz.

----------

## r.stiltskin

Thanks.  That was the clue I needed.  That led me to this http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html#toc1which explains how applications authenticate users.

But I'm still looking for whatever it is that controls permissions of users/groups to access DEVICES.  Any hints?

----------

## kadeux

 *r.stiltskin wrote:*   

> But I'm still looking for whatever it is that controls permissions of users/groups to access DEVICES.

 

Finally it's the kernel which controls the access to the hardware. The "superuser" (usually called 'root' in *nix/Linux) is a special user identified by the kernel with UID (User-ID) 0. Normally in Unices/Linux only the user with UID 0 is allowed to do administrative and security sensitive tasks. And mounting of filesystems, granting rights to other users/groups, editing system-wide configuration files, etc .. are security sensitive. 

To make a long story short, here is a link to one ressource out of many to get the basics:

Secure Programming for Linux and Unix HOWTO: http://www.dwheeler.com/secure-programs/

Read particulary "Chapter 3. Summary of Linux and Unix Security Features".

An application (like mount) can run with root privilege to allow an user to mount a filesystem when the setuid bit is set and the application is owned by root. Applications with setuid can be misused to become root on your system. Additionally the mounting of filesystems not under the control of the administrator can be a security risk, particular when the user mounts a chargeable medium with a setuid program. 

The kernel mounts the filesystem on demand of an appropriate systemcall after it has checked that the _effective_ UID of the process has the value 0.

Therefore the mount command itself checks the UID and will only make a systemcall for mounting when the UID of the user is 0 (root) or the user/users option in fstab is set.

You can achieve more granularity with kernel patches (RSBAC,...) for access control and with extended attributes for some filesystems. But you need a good policy/plan for not breaking things.

 *carl.anderson wrote:*   

> 
> 
> You might want to consider installing sudo.

 

 *truc wrote:*   

> /etc/fstab  <..snip..> Add user if you want simple user to mount/umount your device 

 

 *r.stiltskin wrote:*   

> Thanks guys but those are both workarounds <snip> 

 

You may call it "workarounds", from my point of view both answers shows alternative ways of administrative tasks to get the job done.

 *r.stiltskin wrote:*   

> What determines which groups can do what <snip> 

 

Some tasks are only allowed by the kernel for _effective_ UID/GUID 0 (root). For other tasks the kernel for example compares the effective UID/GUID of the process with the given UID/GUID of a file. The authors/developers/distributors of applications/packages/distributions or standards defines default values for naming schemes and IDs. (It is rumored that sometimes developers of different projects have talked with each other   :Surprised:   ). Files of an audio application may be owned by the system account audio and/or belonging to the audio group. Therefore joining the audio group could be a good idea if you want to play music.  :Cool: 

 *r.stiltskin wrote:*   

> But suppose I want to create a new group, the 'mounties' group, of users who are allowed to use mount (but not any other powers of root). How is that done?

 

Use the "workarounds" that were mentioned above (sudo or options in fstab).   :Wink: 

But if a user can mount *any* medium he/she likes to mount, the user may have more opportunities to get root privileges with malicious apps/tools on that medium.

 *r.stiltskin wrote:*   

> I have tried chmod to change the permissions, but that is ignored. I chown'ed /mnt/memstk to an ordinary user, but still only root could mount a device there and after mounting the owner and group changed back to root root, and only root can open the files. 
> 
> 

 

You should chmod *after* you have mount the medium. The original mountpoint is hidden and not present after mounting.

The file/directory attributes stored on the medium takes effect.

Sorry for the long posting.

----------

## r.stiltskin

Thanks for your answers, and thanks for mentioning Wheeler's book.  That definitely goes on my list of 'things to read.'      :Shocked: 

----------

## Gentree

very enlightening all this but what remains unclear to me is this magical wheel group.

What can / can't a wheeler do ?

I was working on a Suse system yesterday and adding the user to wheel seemed to make no difference to the mount issues.

(Suse do some very odd things but it raised the question.)

I have sudo installed but basically it's empty and any lines relating to wheel are just comments.

Having added a user to wheel he can use mount so where is this behaviour defined?

TIA.   :Cool: 

----------

## kadeux

 *Gentree wrote:*   

> I have sudo installed but basically it's empty and any lines relating to wheel are just comments.
> 
> Having added a user to wheel he can use mount so where is this behaviour defined?

 

The "wheel" group is not required by default to run "sudo" or "mount". 

"su" is part of the shadow package which can be configured to use PAM (Pluggable Authentication Modules) as its authentication framework. The selection of which PAM modules are used are set in different configuration files for each application in /usr/pam.d/. The applications must support pam.

 *less /usr/share/doc/shadow-4.0.7-r4/txt/README.pam.gz wrote:*   

> 
> 
> <---snip--->
> 
> About PAM support in the Shadow Password Suite
> ...

 

"sudo" is an extra package and can also use pam as an authentication framework, but did not use the module pam_wheel.so by default in the configuration file /etc/pam.d/sudo. 

But you can configure the actions that sudo will allow for members of the wheel group by editing the file /etc/sudoers with visudo. (Don't edit it directly, visudo will call your default editor.) First read the documentation for sudo/visudo/sudoers (man -a '*sudo*') because sudo will not run when the syntax is wrong.

Because I'm not very good in explanations, here are some practical examples:

Example #1: Mounting as user 'root'

```
# fdisk -l | grep sda

Platte /dev/sda: 96 MByte, 96206848 Byte

/dev/sda1   *           1         733       93808    6  FAT16

# grep sda /etc/fstab

/dev/sda1               /mnt/cfcard     vfat            noauto,noatime          0 0

# mount /mnt/cfcard/

# umount /mnt/cfcard/

# tail -n 2 /var/log/kern.log

<--snip--> grsec: mount of /dev/sda1 to /mnt/cfcard by /bin/mount[mount:9605] uid/euid:0/0 gid/egid:0/0, \

parent /bin/bash[bash:15031] uid/euid:0/0 gid/egid:0/0

<--snip--> grsec: unmount of /dev/sda1 by /bin/umount[umount:28049] uid/euid:0/0 gid/egid:0/0, \

parent /bin/bash[bash:15031] uid/euid:0/0 gid/egid:0/0
```

Here in the logs you can see which IDs are used: User-ID (uid), effective User-ID (euid), Group-ID (guid), effective Group-ID (egid), Process-IDs (mount:9605, bash:15031). I'm using Hardened Gentoo with grsecurity/pax and syslog-ng, your logs may differ.

Example #2: Try to mount directly as a (new) user 'testuser'

```
# useradd -D

GROUP=100

HOME=/home

INACTIVE=-1

EXPIRE=

SHELL=/bin/bash

SKEL=/etc/skel

CREATE_MAIL_SPOOL=no

# useradd -m -g users -G audio,cdrom testuser

# tail -n 5 /var/log/auth.log

<--snip-->  useradd[14357]: new user: name=testuser, uid=1003, gid=100, home=/home/testuser, shell=/bin/bash

<--snip-->  useradd[14357]: add `testuser' to group `audio'

<--snip-->  useradd[14357]: add `testuser' to group `cdrom'

<--snip-->  useradd[14357]: add `testuser' to shadow group `audio'

<--snip-->  useradd[14357]: add `testuser' to shadow group `cdrom'

#

# passwd testuser

New UNIX password:

Retype new UNIX password:

passwd: password updated successfully

# su - testuser -c 'mount /mnt/cfcard'

mount: only root can mount /dev/sda1 on /mnt/cfcard
```

Example #3: Try to mount via sudo as user 'testuser' without configuring sudoers

```
# su - testuser -c 'sudo mount /mnt/cfcard'

We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.

    #2) Think before you type.

    #3) With great power comes great responsibility.

Password:

testuser is not in the sudoers file.  This incident will be reported.

#

```

Mail message initiated by sudo: 

```
<--snip-->>

X-Original-To: root

<--snip--> 

Subject: *** SECURITY information for <--snip--> ***

<--snip--> : testuser : user NOT in sudoers ; TTY=vc/1 ; PWD=/home/testuser ; USER=root ; COMMAND=/bin/mount /mnt/cfcard
```

Example #4: Configuring sudoers with visudo

```
# visudo
```

(edit file with your default editor invoked by visudo, don't change the temporary filename when saving)

```
#

# tail -n 3 /etc/sudoers

testuser        replace-with-your-hostname=/bin/mount /mnt/cfcard

testuser        replace-with-your-hostname=/bin/umount /mnt/cfcard

# su - testuser -c 'sudo -k'

```

Example #5: Mounting via sudo as user 'testuser' after configuring sudoers

```
# mount | grep sda

## su - testuser -c 'sudo /bin/mount /mnt/cfcard'

# mount | grep sda

/dev/sda1 on /mnt/cfcard type vfat (rw,noatime)

# su - testuser -c 'sudo /bin/umount /mnt/cfcard'

#
```

OK, it's working!   :Wink: 

Example #6: Testing the ruleset

```
# su - testuser -c 'sudo -l'

Password:

User testuser may run the following commands on this host:

    (root) /bin/mount /mnt/cfcard

    (root) /bin/umount /mnt/cfcard

#

# su - testuser -c 'mount /mnt/cfcard'

mount: only root can mount /dev/sda1 on /mnt/cfcard

# su - testuser -c 'sudo /bin/mount /mnt/cfcard'

# mount | grep sda

/dev/sda1 on /mnt/cfcard type vfat (rw,noatime)

# su - testuser -c 'sudo /bin/umount /mnt/cfcard'

#

# su - testuser -c 'sudo /bin/mount /boot'

Sorry, user testuser is not allowed to execute '/bin/mount /boot' as root on <--snip-->

#
```

Rules seems to work fine.    :Cool: 

But there are different ways for allowing users to mount specific partitions, sudo is only one solution. But sudo can offer much more than this.

*EDIT*: Removed italic font for "replace-with-your-hostname" because that don't work in a code segment.   :Crying or Very sad: 

But you will replace it with your hostname anyway.

BTW: I'm using "su sudo" here because I'm to lazy  (  :Rolling Eyes:  )  to login as testuser to test the user.   :Confused: 

----------

