Linux permissions: How To

[thewanderer]

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

[thewanderer]

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]

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: http://forums.debian.net/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.

[Polaris96]

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.

[thewanderer]

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.

[Polaris96]

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.

[thewanderer]

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...

[Polaris96]

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...

[thewanderer]

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

[Polaris96]

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.

[thewanderer]

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.

[Polaris96]

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.

[thewanderer]

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.

[Polaris96]

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.

[rayburn]

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.

[Polaris96]

@rayburn: no problem. I've learned far more by helping novices than I ever did in school or on the job. Regret we will need a bit more info. We know that you have multiple PCs tied with NFS and that you're curious about the thread. Here's what you need to tell us:

1. Is the network "working"? Can you see the and access the NFS shares from the client machines?

2. If so, what are you doing with the NFS shares at the moment (pictures, music, file storage) And is it working the way you want it to?

3. What do you want to do after reading this thread (for instance "I want to store software in the NFS share and run it from the client")

[rayburn]

Many thanks for your swift reply. There is no problem with the network working as such, just that as we use the server to store photos, music, etc. on, I need each user to be able to access this material. ATM, the server doesn't recognise the user who is logged on at a client even though all users have an account on the server. What I am really asking I suppose is how do you get the whole network to recognise an individual regardless of where he/she is logged on.

The server is running Debian, all clients except myself are on Mint, and I am running Crunchbang.

Does this help?

[Polaris96]

Sounds like your problem could be with NFS. We need to deal with your problem by first identifying exactly what you want to do and then breaking the goal into bite sized pieces that we can tackle together.

If you need help with the concept of NFS, check my tutorial "How to share files with NFS" it's on page 3 or 4 of the HOW - TO section of this board. Make sure you have followed the steps there to set up your NFS shares. Once we've confirmed you have your NFS shares set up right, we'll look harder at permissions.

Then, tell me what you are trying to do. Can you see the share on the client? can you mount it? can you read files? can you write? can you execute?

We need to eat the elephant one bite at a time. If you want to start with pure concept, read the NFS tutorial first and then ask a few questions. I'll answer them and you can ask a few more. I know you're probably a bit frustrated, now. But, I need more specific questions to help you out. Keep at it. you're already further along than 90% of PC users. Nothing worth doing is easy at first.

[rayburn]

Thank you for your encouragement, I will go and read that tutorial and get back to you.

Cheers!

[eric1959]

Thanks for letting me know about other good stuff !

What other good stuff.....