Linux permissions: How To

Share your own howto's etc. Not for support questions!

Linux permissions: How To

Postby thewanderer » 2009-06-27 00:07

Section 1: Introduction to Linux permissions
Linux is today considered the most secure operating system by many. One of key factors to system security is access permission control. All modern operating systems support this feature, which I believe first appeared in UNIX operating system. It allows file owners to restrict who can read, write, execute and otherwise change files, running processes ('tasks') and other parts of the system.

Linux, as every UNIX-like OS, has a built-in file permission control system. It assigns the following attributes to every file on its file system:
  • Owner - user who owns the file, has unlimited control over it and can change other file attributes.
  • Group - user group that the file belongs to.
  • UNIX permissions - a set of rules defining who can do what to the file. Fear not, it is discussed below.

You can see what user and group you are by issuing the following command in a terminal emulator (try gnome-terminal or konsole):
Code: Select all
id -a

uid will tell you who you are (as if you didn't already know this), gid is your primary group, and groups - all other groups your user belongs to.

Used terms:
file system - an on-disk structure holding descriptions of files (such as the attributes mentioned above, file modification date etc.) and the files' contents themselves. File systems are contained in disk partitions (also called slices). Most popular file systems today are ext3, xfs and reiserfs. If you run Debian, you probably use ext3.
Worth mentioning is the fact that directories ('folders') are also considered files, simply containing other files. Therefore, permissions apply to directories, too.

user group - in UNIX-like systems, every user is assigned to some group. Users in the same group may share rights, for example a file's permissions may be set so that all users in a group can modify its contents.


Section 2: UNIX permissions explained
Having learnt the theory, it's time to pass on to practice - what do UNIX file permissions look like and how to use them?
First of all, let us examine the permissions of an example file. By issuing the following command in Linux console or a terminal emulator:
Code: Select all
stat /etc/hostname

you will see a list of file's attributes. It includes file type (it could also be a directory, a symlink, etc.), file size et cetera and a line like quoted below, which is the item of our interest:
Code: Select all
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Obviuosly, the file is owned by root user (system administrator) and belongs to root group. After the slash, numeric user ID's are shown - that's the way they are stored in the filesystem, in order to conserve disk space.

Access field contains an octal number and its human-readable representation (I personally consider the numeric one to be more readable). It is crucial to know what the permission number means.
It consists of four digits, ranging from 0 to 7. For now, we shall skip the first one and focus on the last three, as they are used most commonly on every system. In our example, those are 644.
Each digit may be a sum of 4, 2 and 1, but not every component has to be included, giving a possible range from 0 to 7. Below is the meaning of the sum components, with Subject being user, group or others, as discussed below.
  • 4 - read permission. Subject is allowed to read the contents of the file.
  • 2 - write permission. Subject may modify file contents, move the file or delete it. With directories, it allows the subject to list its contents in conjunction with 1.
  • 1 - execute permission. Subject may execute the file, provided that it is a program or a script. In case of directories, execute permission lets the subject traverse through directory into subdirectories. See the note on path handling below.
Therefore, number 5, for example, would mean: a permission to read and execute, but not to write.

The digits define respectively: owner, group and others' permissions. Therefore, we can see that, in our example, file owner (root) may write to the file and read its contents, while group 'root' and other users (not being root nor a member of group 'root') are given the right to read the file.
Now, compare it to file permissions of /etc/shadow (use 'stat' again). This file has 0 as the third meaningful digit, so users not being root nor in group 'shadow' may not even read the file. You can easily confirm that by running a text editor and trying to open /etc/shadow - you, as a regular user, should not be allowed to see its contents as it contains system-wide passwords (and this is beyond the scope of this little How To).

A note on path handling
To access any path in the filesystem, the user (which the particular process is running as) needs at least execute privilege for all its parent directories. Therefore, if you try to access an example file /etc/security/limits.conf, even though it has a mode of 0755 (for the sake of example), it does not necessarily mean you are free to read it. To read the file, you have to be able to 'execute' all of its parent directories, so you need execute permission on /etc and /etc/security. If either /etc or /etc/security has permissions set so that you are not allowed to execute it (1), then reading /etc/security/limits.conf will fail. This rule applies anywhere in the filesystem.

Section 3: Modifying file permissions
This section shows, using an example, the very basic usage of chmod command. Chmod is one of sysadmin's best friends and the standard tool for manipulating file permissions in various Unices (also works with *BSD and Solaris!). Let's begin...
First of all, create a file for demonstration purposes. In the example, I will be using name testfile. Commands below are to be executed in a terminal emulator or Linux console. You can basically just copy, paste, and see how it works.
Code: Select all
# first of all, create the file using touch command (see 'man touch' for details)
touch testfile
# now, let's see its permissions
stat testfile
# modify the file so that group members and other users can write to it
chmod 666 testfile
# see the new permissions
stat testfile


Have the file permissions changed? You can verify that it actually worked by starting a new session and logging on to another user account, or issuing su username.
If you only have one user account, create a new one for testing:
Code: Select all
su
(your root password here, to log on to root account and add a test user)
adduser demo
# you can remove this user when you've finished: deluser demo

Now, log on to demo, open testfile (in your regular user's home directory) and type something in it. Save, and then check with your own user's account that it contains whatever you may have written. Voila!
You may now want to check it with various different permissions. Try chmod with arguments like 644, 640 and so on.

To be continued in part 2
Last edited by thewanderer on 2010-04-06 17:36, edited 1 time in total.
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Linux permissions: How To - real-life scenarios

Postby thewanderer » 2009-06-27 00:24

Section 4: Example scenarios involving chmod
You now know how to change file permissions. However, how can they be useful in real life besides letting your buddy leave you a random message in your own text files?

Case 1: family photos
Situation: You store family photos in directory Photos on your user account. Several other family members use the computer and you want them to be able to access the photos.
Question: How to set directory permissions so that other users can see your files and their content?
Answer: Set the directory to 755 and all files under it to 644:
Code: Select all
chmod 755 Photos
# Photos/* means all files in Photos directory
chmod 0644 Photos/*



Case 2: Software and data files for your department at work
Note on below: ~ means your home directory.
Situation: In your home directory you have a program in ~/AppSoftware/program.bin . It stores your department-specific data files in ~/OurData. The system operator has assigned you and other people in your department a user group 'mydept'.
You want other people from your department to be able to run the provided software and to write the data files. At the same time, other people from outside the group should be allowed to run the software but not to modify the data. For simplicity's sake, we skip things like logging who added/removed what in terms of data (logging is a necessity in real life), focusing only on appropriate permissions.
Question: How to allow execute access for a group to one file (program binary) and read-write access to other directory for the same group, while denying world (other users) access?
Answer: In our example, this would be:
Code: Select all
# below: -R flag, affects the directory and files/subdirs inside
chmod -R 0755 ~/AppSoftware
chmod -R 0770 ~/OurData

In case files have a wrong group attribute set, you can correct it by first running chrgp -R mydept files, where mydept is the group name, files is file path, and -R switch tells chgrp to run recursively (see above code example). Chgrp changes files' group to the one given.


Case 3: Classified files
Question: How to protect files that are to be kept secret?
Answer: A very basic protection can be achieved by chmodding the sensitive files/directories to 0600. However, remember that the system administrator (root) can still access them, regardless of set file permissions. Therefore, besides locking down file permissions, it is highly advisable that you encrypt the files using strong encryption software (try gpg encryption via programs like KGpg, or see ccrypt - symmetric cryptography).
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Linux permissions: How To - ACL

Postby thewanderer » 2009-06-27 00:58

UNIX permissions and their limitations
Examples above show the usefulness of UNIX file permissions. You can grant users from your group access to your files, expose them to the whole world or have them only for yourself. However, there are use cases in which this access control model is not enough.
Assume that you are on a large system (perhaps a server) and, together with several dozen users you are members of group 'users'. Now, you want to make some of your files available to just one of them so that the others can not read it. How can UNIX permissions benefit you?
In short: they can not. You are now dependent on some other means of exchanging files like e-mail or IM. Or, alternatively, you can make use of...
Access Control Lists in Linux
Access Control Lists (called ACL) are an extended means of defining access rights to files and objects. They allow you to specify file permissions in a more fine-grained way, assigning any user or group (besides owner and file's set group) different privileges. For instance, you may share a file with just one specific user, no matter what group they are in.
How to make use of this new, powerful feature?

First, make sure your system supports ACL. Several criteria must be met before you can enable ACL for your files.
Check your kernel version. If it is anything later than 2.6.18, then chances are you already have ACL support built-in. (I'm not quite certain at which version Debian kernels received the ACL patch).
The next thing is acl package, required for ACL attribute manipulation. You can install it by issuing:
Code: Select all
 # if you are not logged on as root, use 'su' first
apt-get install acl

Alternatively, you can use Synaptic package manager to get and install the package. If you are not the system administrator, ask your sysadmin to enable ACL on your machine.
Once you have installed acl, you can try and see if your file system supports it. Example command (I assume that file 'testfile' exists):
Code: Select all
setfacl --modify user:demo:5 testfile

If setfacl complains about an error, you probably need to mount your filesystem with acl option. Assuming that the filesystem 'testfile' is located on is / , execute the below as root:
Code: Select all
mount -o remount,acl /

Try setfacl again. If successful, a call to:
Code: Select all
getfacl testfile

should show, among others, a line like this:
user:demo:r-x
Here, rx means 'read, execute' permission, which is equivalent to 5. To see if Access Control Lists work, set the file permissions on testfile to 700 using chmod and try to open it from 'demo' user account. If successful, ACL did override UNIX permissions indeed. Your file system is now ready for granular access control with ACL!

Note: To enable acl permanently for certain filesystems, you should include acl option in /etc/fstab. Please refer to fstab(5) manual page for instructions.

Example uses of setfacl to manage file permissions
Code: Select all
setfacl -R -m user:josh:6 filedir   # sets read-write permissions for josh on filedir and all its contents
setfacl -m group:junior-sys-admins:4 /var/log/apache2/error.log    # let group members of junior-sys-admins read Apache2 error log file
setfacl -m user:evilcraig:0 my_notes.txt    # prevent user evilcraig from accessing my_notes.txt


Default (inherited) ACL
Default ACL are an invaluable tool when making a directory that you want to share for reading or writing among users. This hint is inspired by this thread: viewtopic.php?f=10&t=53591
Default ACL are access control entries that get inherited by all sub-items of a directory (recursion deeper is allowed!). Thus, if you want to create a directory for bob and fred so that both can work on each other's files, the below should suffice (notice the -d flag to setfacl, it sets a default ACL):
Code: Select all
mkdir common_workspace
setfacl -m u:bob:7 common_workspace
setfacl -d -m u:bob:7 common_workspace
setfacl -m u:fred:7 common_workspace
setfacl -d -m u:fred:7 common_workspace


Now, whenever a file gets created, it retains its original owner and group, but should automatically get assigned the above ACL. This is, for example, useful when you have users co-working on website development. You can use Apache or PHP running as www-data, write a script to change file ownership upon creation to www-data (inotify helps!), and all files are still writable by bob and fred, your Web developers.

Appendix: Some hints
  • On Debian systems, every user is traditionally assigned their own group. File sharing may be accomplished by adding one user to other's group, as shown below (only to be done as root):
    Code: Select all
    adduser me otherguy # adds user 'me' to group 'otherguy'

    Then, 'otherguy' can just set their files to 0750 or whatever permissions they want you to have. However, this is the old-fashioned approach to granular file permissions and should be avoided whenever possible in favour of ACL.
  • Konqueror (at least in Debian Squeeze) supports ACL out-of-the-box when filesystems are mounted with acl option. It allows for easy, graphical management of extended access rights, similar to that of Microsoft Windows.
  • You can find a wonderful but pretty old (still current, though) ACL guide here: http://www.vanemery.com/Linux/ACL/linux-acl.html

That's all! Have fun and thanks for bearing with me.
Last edited by thewanderer on 2010-07-16 13:22, edited 1 time in total.
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-07-21 16:08

Thanks very much for taking the time to write this tutorial. Permissions are super useful and they seem to never blip on the radar of people migrating from win. With your permission, I'd like to add one item to your instructions regarding directory permissions. You did cover it briefly, but directories can be kind of counter intuitive and people get wrapped around the axle trying to logic out why they can't get into a directory:

Scenario: You want to make a directory that everybody in a group can access. You start like this:
Code: Select all
 ~/#mkdir groupd
  ~/#chmod ug+rw groupd
  ~/#chmod o-rwx groupd
  ~/# chown root:newgrp groupd  (you could also use the chgrp command)
  ~/# ls -l
  drwxrw---- 1 root newgrp 10 2009-07-20 12:36 groupd]


ok, what do we have? a directory with rwx permission for the owner and rw for the group and the world is locked out. Good. Now, to test it, become a normal user in groupd and try to access your new directory:
Code: Select all
  ~/#exit
  ~/$groups
joeblow blahlblah blahblahblah newgrp

Now, we've confirmed we're in the correct group. Let's check it out.
Code: Select all
  ~/$cd groupd
bash:  cd: groupd/: permission denied

WTF?!? why can't I get in. The reason is that you need to enable EXECUTE permission to allow anyone to enter or use the directory. You can think of a directory, in some ways, as a program or script that executes when called with the "cd" command. So code:
Code: Select all
 ~/#chmod g+x groupd
  ~/#exit
  ~/$cd newgrp
  ~/newgrp$

Sorry for belabouring this, but getting stuck with directory permissions is the most common mistake I find when teaching this stuff to people.

One last thing: You can't do this:
Code: Select all
drwx---r-x 1 root newgrp 10 2009-07-20 12:36 groupd

By that I mean you can do it in the sense that chmod will execute the command. BUT when the world tries to enter the directory they will get "permission denied"

You can't use UNIX permissions to exclude a particular group from a directory (you can do that in *nix, but not this way). That's one of the places where ACL is the right tool to use.

Like hosts.*, iptables, route, and most other utils, the permission is read in a specific order and the process exits as soon as an answer is obtained. The command looks from owner to world and the first exclusion causes the command to exit. That means that if the user isn't allowed, say, to write, then the group and others will not have write access REGARDLESS OF WHAT YOU DO WITH CHMOD. Don't be fooled by the sticky bits in ls -l.
Last edited by Polaris96 on 2009-07-27 20:13, edited 2 times in total.
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby thewanderer » 2009-07-25 11:06

Thank you for explaining the tricky parts. Those hints are invaluable as users ascend on their way to becoming a Linux Guru.
I think that the entropy found on these forums collected would make nice wiki entries. Not at all Debian-specific, but serving as a semi-complete guide to GNU/Linux.
The Ubuntu folks have already started a huge documentation project and are posting tips&tricks like crazy to their wiki. However, as soon as you dig further into their docs, it seems to lose quality. And they are focused on the desktop side, not the core basics of their operating system. What is being produced here could fill the gap that is between desktop-centric documentation of current 'user-friendly' distributions and very specific tutorials targeted at professionals.
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-08-07 00:03

We're going to revisit the way workgroups worked in the '80s

Lots of times in days of yore, you had a situation where a big (say, engineering) company had a supercool supercomputer with all the developers having their own user accounts. These monsters usually ran system V, POSIX, or one the other AT&T'ish flavours of terminal UNIX.

(historical note: back in the day, GOOD engineering software CAD/CAM, FEA, synthetic SPICE, was too big to run on PCs)

We needed a way to allow people to work together on a variety of group projects that wouldn't restrict access the membership but would keep everyone else out. Today, this could translate to a home use of, say, George and Jane want to keep home finances on a shared directory and restrict access to Elroy and Judy. BTW George and Jane should each have their own account.

What you want to do, here, is set the Group ID for the folder. This is pretty advanced stuff, permission wise but it's easy to do. First make a group:
Code: Select all
~/#addgroup bills


Then, we add George and Jane to that group:
Code: Select all
~/#usermod -aG bills George
~/#usermod -aG bills Jane


note: don't forget the -aG: if you forget the 'a', YOU WILL REWRITE THE GROUPLIST FOR THE USER. thus, George would only be a member of bills. To fix this, if you ever do it, you need to figure out all of the groups George was a member of and add them with usermod -aG [g1],[g2],[g3]... If you do this once, you'll never do it a second time.

Now, we make a directory where the bills can be shared:

Code: Select all
~/#mkdir /home/bills


this will come up as follows:
Code: Select all
~/#ls -l /home
drwxr-xr-x   2 root root   48 2009-04-11 08:32 bills

plus whatever else is in /home. Notice the owner is not so good - root and root group both own the directory. We need to change that.

Code: Select all
chown root:bills /home/bills
ls -l /home
drwxr-xr-x   2 root bills  48 2009-04-11 08:32 bills


OK, we also need to give the group some write priviledges and restrict everybody else (remember, to keep somebody out of a directory you need to restrict EXECUTE priviledges)
Code: Select all
chmod g+rwx bills
ls -l
drwxrwxr-x   2 root root   48 2009-04-11 08:32 mnt
chmod u-rwx bills
ls -l
drwxrwx---   2 root root   48 2009-04-11 08:32 mnt


Almost done. Let's recap what we have here. Our directory lets the owner (root) and group members write to it and read it. it keeps the rest of the world out. Sounds good, right?

Try this:
Code: Select all
george@jetson:/home$cd bills
george@jetson:/home/bills$touch cable.bill     #note: the touch command creates an empty text file.
touch: cannot touch `cable.bill': Permission denied


Hmmm. That doesn't look right. Here's the problem: whenever you try to save a file it defaults to your Primary group. In george's case, that group is george. In your case it's $YOURNAME. But the only group that has write permission for 'bills' is 'bills'. How do we fix this?

We could use the newgrp command, like this:
Code: Select all
newgrp bills

from george's terminal. this will reset his primary group IF he is a member of the group he wants to switch into.

You're underwhelmed, right? Good, you should be. What a pain. The REAL way to do this is like this:

Code: Select all
~/#chmod g+s bills
ls -l
drwxrws---  2 root bills 48 2009-08-04 16:37 bills

Look at the permissions "drwxrws---" We haven't seen an 's' before, right? That indicates the group ID is SET. Any files written to the bills directory will now automatically retain the group 'bills' no matter who wrote them or what the user's primary group was. Let's recap:

1. Only users within the group can enter the directory and read the files
2. All files saved become group property, so other group members have acess to them
3. If a group member saves a file outside the directory, they retain their original primary group.

So that's how we do it. Cheers.
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby thewanderer » 2009-08-29 17:40

Here's a pitfall that makes me wonder at nights:
Lines that I type begin with $

Code: Select all
$ groups
users disk cdrom sudo audio www-data video plugdev netdev powerdev qemu kvm scanner fuse

Notice plugdev above and read on.

Running from ext3 partition
Code: Select all
$ stat /usr/bin/pmount
  File: `/usr/bin/pmount'                   
  Size: 42168           Blocks: 88         IO Block: 4096   regular file
Device: 801h/2049d      Inode: 299360      Links: 1                   
Access: (4754/-rwsr-xr--)  Uid: (    0/    root)   Gid: (   46/ plugdev)

$ /usr/bin/pmount
Printing mounted removable devices:
To get a short help, run /usr/bin/pmount -h


Running from NFSv3, chrooted onto the mount (also tested with nfs-boot)
Code: Select all
$ stat /usr/bin/pmount
  File: `/usr/bin/pmount'
  Size: 42168           Blocks: 88         IO Block: 131072 regular file
Device: 13h/19d Inode: 696892      Links: 1
Access: (4754/-rwsr-xr--)  Uid: (    0/    root)   Gid: (   46/ plugdev)

$ /usr/bin/pmount
bash: /usr/bin/pmount: Permission denied

$ # confirm that we are still in plugdev group
$ groups
users disk cdrom sudo audio www-data video plugdev netdev powerdev qemu kvm scanner fuse
$ # change our PRIMARY group to plugdev
$ newgrp plugdev
$ /usr/bin/pmount
Printing mounted removable devices: ...


I've also tried the same from outside the chroot - same results.
It turns out that Linux permission handling is not as clear as I thought it to be...
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-09-21 20:34

This sounds more like a client/server permission issue than a user permission issue. Try running pmount over NFS as root. I bet you'll still get denied.

Checking the pmount manpage shows nfs isn't listed as a supported file format for pmount.

You might try adding
Code: Select all
pmount: [client name]

to /etc/hosts.allow on the server machine. This would be a hack and I've no idea whether or not it would work.

The problem you're having doesn't involve user permissions. It's a compatibility issue, so far as I can see.

What do you want to do? Maybe we can come up with a workaround...
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby thewanderer » 2009-09-22 18:37

Hi,
I did not mount the NFS share by pmount, but by mount as root (-o rw,hard,intr,suid) - it is not user-mountable anyway. I wanted to run the pmount binary from the NFS share as an example of group-executable program that requires being in group plugdev. pmount is in no way related to the NFS share itself, other than it is located on it.
Well, check it on your own: create a group-executable (but not world-executable) binary on an NFS share, add your user to that particular group and see if you can call the program without issuing `newgrp` first. It works on local filesystems for me, whereas with NFS access is denied.
Of course, there is a workaround which takes no more than:
Code: Select all
newgrp plugdev

(or, generally, any other group you need at the moment)
The purpose of my previous post was showing a possible pitfall in Linux permission handling. I don't know if it only concerns my system, but the symptoms show that it is not purely an NFS issue.
Here is a test case. Try to confirm it if you wish:
Code: Select all
# just to be sure
thewanderer@serenity ~ $ mount | grep /mnt/nfs
sun:/srv/somefs on /mnt/nfs type nfs (rw,hard,intr,addr=192.168.1.50)
# get a new binary for testing
thewanderer@serenity ~ $ sudo cp /bin/ls /mnt/nfs/lsbin
thewanderer@serenity ~ $ sudo chgrp audio /mnt/nfs/lsbin
thewanderer@serenity ~ $ sudo chmod 0750 /mnt/nfs/lsbin
thewanderer@serenity ~ $ groups
users dialout cdrom audio video plugdev netdev powerdev
thewanderer@serenity ~ $ /mnt/nfs/lsbin
bash: /mnt/nfs/lsbin: Permission denied
thewanderer@serenity ~ $ newgrp audio
thewanderer@serenity ~ $ /mnt/nfs/lsbin
file1 file2 Desktop crap.txt


Just FYI: Linux serenity 2.6.30-1-amd64 #1 SMP Sat Aug 15 18:09:19 UTC 2009 x86_64 GNU/Linux
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-09-22 23:00

I can run binaries and other executables on my NFS shares when they are group accessible and owned by someone else even if the group is secondary for me. So the real question is Why can't you?

It took a little while to find the info about gids and NFS shares. It's all in the manpages. Check out the pages for nfs, exports, and mountd.

The explanation of what's going on is in the exports manpage under User ID Mapping.

I think the groups ID numbers for your groups are different on the client than they are on the server. make a new group on both machines

Code: Select all
addgroup --gid 2001 nfsgrp
usermod -aG nfsgrp [your name]


then repeat your experiment. There's a reasonable chance everything will work with the GIDs synced up like that.



There are two options that "jump out" irt your problem:

1. You can write a launcher script to change the primary group and grab the required file off the share. Stick it in the home directory.

2. You can implement ACL instead of simple permissions. NFS supports ACLs.

Both of these are bandaid hacks. I believe simple permissions can be made to do what you want but its tricky. I'm playing with this now and will post again when I have it worked out.

Try mounting the share with no_root_squash. See if that helps.
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby thewanderer » 2009-09-24 13:12

On the client
File stat shows:
Code: Select all
Gid: (   29/   audio)


I am in 'audio' group, as shown in the post above. /etc/group contains:
Code: Select all
audio:x:29:thewanderer


On the server
File stat shows the same, but user thewanderer (which exists) is not in group audio.
After adding thewanderer to audio on the server and restarting nfs-kernel-server, it works like a charm.

My conclusion
When accessing a file, NFSv3 sends current UID and primary GID to the server. However, secondary groups are not sent. My NFS server checked the group access first against the GID sent by the client, and then against locally stored group memberships. If thewanderer was not a real user on the NFS server, the server would probably assume that the only group I am in is 100 (my primary group on the client).

Worth noting, I think.
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-09-24 14:25

Definitely. And also good deal its working.

You actually DO send your secondary GIDs, as well as the primaries. The splitting point is that you're sending the GID, which is numeric. You're NOT sending the groupname, per se. Your fix works because one of the GIDs that rpc turfed into the server with its request matches the corresponding GID on the server.

In the dark old days before speciailized net management apps and LDAP, this kind of thing was the paydirt of net admins. I inherited a toolkit full little "sync scripts" from one my mentors. One of these will sync up the UIDs and GIDs across a network. I later wrote my own version of it, which I still use frequently.

You should do this for the exercise. It's pretty simple BASH scripting, and it makes you comfortable working with passwd, shadow, groups, and the usermod and useradd utilities.
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby thewanderer » 2009-09-24 19:55

Well, the GID did actually match (equal numeric value on both sides) even before I added thewanderer to group 'audio' on the server. Are you sure secondary GID's get passed to the server in NFSv3? My results show quite the contrary. Do I miss a point?

And yes, I do have to sync UIDs and GIDs on machines scattered all over the place. Till now, I had an NFS-booted environment, so /etc/passwd and /etc/group were centralized. I'm currently migrating to somewhat fatter clients with disks, and it's becoming a hassle over time.
thewanderer
 
Posts: 416
Joined: 2007-03-19 18:11
Location: my desk, Warsaw, Poland

Re: Linux permissions: How To

Postby Polaris96 » 2009-09-24 23:44

The generic answer for your problem, these days, is LDAP. I don't recommend using it. Home networks and even smaller enterprise networks can be manually synced up w/o too much headache.

The secondary GIDs definitely ride along with the access request. All of the forensics for this thread have been done on nfs3 with the executable on the server owned by a secondary group (I used fuse b/c it was handy) and disabled for world access. I never had to use newgrp.

It was much tougher to simulate your problem than to identify it once I had. If your IDs match on both machines, permissions are normal and seamless.

Whenever I have problems with this stuff, I always start with basic premise that the code isn't broken, I'm just doing something wrong. The major bugs were worked out of services on this level by 1990. It's not that bugs can't occurr, but they almost never do. We're in the heartland of UNIX, here, not the frontier.

...Which is why I don't think everybody should run to LDAP. If you sync the data files in both (or all) machines, you're promoting stability AND performance, because you're leaving fewer ambiguities in the system to trip up commands. LDAP is a relatively quick "rape and pillage" fix. I feel like a properly tuned "regular UNIX" network functions better, though (no supporting data I just think so).

Once you've decided on your id's it isn't too hard set fresh machines up in your pattern at the outset. I like using BASH with diff and a dose of sed to "find and replace" IDs and loop it until everything is tight.
for as long as the world remains. for as long as time remains. so, too, will I remain. To serve. To help. And to make my contribution. Also, never forget our family at debianuserforums.org If we can't solve your problem, they probably can.
Polaris96
 
Posts: 555
Joined: 2009-06-17 18:37

Re: Linux permissions: How To

Postby rayburn » 2009-09-30 19:51

OK, please bear with me as I am struggling to understand some of the info in this thread, and the answer to my question probably is already there...

The challenge: I have a home network (NFS) with 4 computers + a server. I am finding it difficult to grasp the concept of users being able to access files on the server. I suspect that my problem lies with uid/gid and I would be most grateful if someone could explain how to sync the users on the server with the users on each individual PC.

Apologies for not explaining my problem very clearly, do ask if you need more info.

Thanks.
rayburn
 
Posts: 24
Joined: 2008-05-29 18:56
Location: UK

Next

Return to Docs, Howtos, Tips & Tricks

Who is online

Users browsing this forum: No registered users and 4 guests

fashionable