I really hate 'permissions'

[SJ]

Okay, so I have a fileserver running here (local-only).

It contains 2 hard disks: a 160GB one for Linux and swap, and a 1TB which is completly accesible by anyone on the network (with some security via users).

All users who are granted access, are members of the group "afp".


Whenever someone copies a file to the server, it is by default set on "<username:username>" permissions, which needs to change into "<username:afp>" by default for all new files/subdirectory's.


The main directory (and currently all data on it) are set with <username:afp> at the moment, but I really don't like doing chown -R <username:afp> with every new file that appears on the server.


Please, please note that I'm not much of a Linux-guy, yes I know how to manually configure files and such, but only by following good guidelines.

[james147]

How are you sharing the files? samba?

[oshunluvr]

There's a couple ways to handle this. I assume you're using NFS, otherwise samba would be stripping most of your security. Most of samba security is within the samba config.

BTW, I will agree permissions are a PITA but they are one of the MAIN reasons linux is virtually virus free. Complain if you like, but I've never had or known anyone who lost data to a virus with linux - and MANY myself included that have lost data to a virus using Winblows. I once got an email from a friend that when opened, launched a virus that started eating my mp3 files. This was back in the early 90's (when I still used Microsuk). We're all better prepared to handle those things today, but linux has been fully prepared since day one. OK, off the soap box and back to the issue...

If are are indeed using NFS, you can apply user control with permissions on the server export or the directories themselves. The client mount will assume the ownership, group and permissions of the export. I too have a server at home and have played with several different setups. What you should do depends on the required level of security (read "safety").

1. Since you assigned all your users to a single group for this purpose (I use the group "share"), you can and should add the "setgid" bit to the exported directory to -prevent accidental mis-assignment of GID (group id). This might happen when you access the server directly to add files or do some maintenance. If you access the shared directory, any files you touch may take your user or root primary group instead of the "afp" group. To do his, add 2000 to your octal directory and file permissions. I.e. if you wanted full group access but no one else you might use 770 (which actually id 0770). Change this to 2770 and now any files touched will take the group id set in the directory ownership. The non-octal version of this is g+s so the command would be chmod g+s foo. If you use the "sticky" bit, all users could access the files, but only delete the ones they own. This is done with octal 1000 or o+t.

2. In my case, I also have a couple programs that access the shared partitions directly (without a human user) and I wanted to allow these programs and any remote user to edit any file. The simplest way to do this is to export the directory with UID (user ID) and GID set. Then, during any remote access all files end up with the same UID and/or GID. Simply add all_squash,anonuid=1001,anongid=1001 to your export. Obviously, use whichever UID or GID you want. I use "nobody" as the user (UID 65534) This by itself will not change ownership of files directly accessed from within the server, just through the exported mounts. In my case, I also export a partition without these options for my users to back up their homes without sharing them. You can also use these options to manage different UID's on multiple systems.

3. Another way to handle this is use a common group as the primary group for all your users and then change the umask to control access. This will take some effort, so I'll avoid the topic for now.

Here's a quick review of permissions in case anyone needs it:

Octal	Alpha	Description
0400	u+r	owner read
0200	u+w	owner write
0100	u+x	owner execute files and traverse the directory
0040	g+r	group members read
0020	g+w	group members write
0010	g+x	group members execute files and traverse the directory
0004	o+r	everyone read
0002	o+w	everyone write
0001	o+x	everyone execute files and traverse the directory
4000	u+s	sets the setuid bit
2000	g+s	sets the setuid bit
1000	o+t	sets the sticky bit

Simply add the numbers together or string the alpha characters together to get your desired permissions.

You may use a+ in place of ugo+

Example: 0775 = u+rwx g+rwx o+rx = ug+rwx o+rx = a+rx ug+w

[SJ]

Oshunluvr, first of all I'd really like to thank you extremely much for your effort and time by putting up that reply for me!


However, as I'm not entirely sure how to do it exactly (I'd prefer doing it via console) I'd really like to hear more on how to do this specifically:

1. Since you assigned all your users to a single group for this purpose (I use the group "share"), you can and should add the "setgid" bit to the exported directory to -prevent accidental mis-assignment of GID (group id). This might happen when you access the server directly to add files or do some maintenance. If you access the shared directory, any files you touch may take your user or root primary group instead of the "afp" group. To do his, add 2000 to your octal directory and file permissions. I.e. if you wanted full group access but no one else you might use 770 (which actually id 0770). Change this to 2770 and now any files touched will take the group id set in the directory ownership. The non-octal version of this is g+s so the command would be chmod g+s foo. If you use the "sticky" bit, all users could access the files, but only delete the ones they own. This is done with octal 1000 or o+t.

Am I right that this will also make new files (files copied over from clients to server) inherent the "afp"-group automatically? If so, I'd almost beg you on my bare knees to explain how I can exactly do this It's the only step I have to take to make this server completly up&running, since I was capable of turning on other things like, for example, wake-on-lan.

Also, there's one user connecting via samba, but I'm not going to do anything special about that since it's only one person. The rest is connecting through AFP (an Apple file transfer protocol), since the other clients are mainly Mac's.
They do authenticate via the Linux-user however and all of which are in the "afp"-group indeed.
A file now typically gets the <username:group> permission when something new is added on the server by one of them.

Again, I appreciate your effort and time so far!

Oh, and on a side-note: I can see why permissions are very important.. But they're really a pain in the *ss for me (setting it up, I mean).

[kubicle]

Am I right that this will also make new files (files copied over from clients to server) inherent the "afp"-group automatically?

It should. New files and subdirectories should inherit the afp-group if sgid bit is enabled in the share directory (new subdirectories should also inherit the sgid bit, so they will behave the same way).

Command to enable sgid bit on shared directory:

sudo chmod g+s /path/to/the/shared/directory

Note that the change won't affect existing subdirectories (only new subdirectories...so you might need to set sgid for existing subdirectories as well)

You can check the sgid bit with 'ls -l', if it's enabled your directory permissions should include an 's' in the group execute position:
drwxrwsr-x

[oshunluvr]

Simple enough to set the setgid bit.

1. Unmount the exported directories on all your clients
2. Log onto the server

For each directory you're exporting this way;

3. Change all the files and directories to the desired group: chgrp -R --preserve-root afp /<YOUR DIRECTORY PATH>/*
4. Change all the permissions: chmod -R --preserve-root 2770 /<YOUR DIRECTORY PATH>/*

This will modify all the subdirectories and files in the path you put in <YOUR DIRECTORY PATH>. If you wanted a different set of permissions, like to allow other users not in the afp group to at least view files - use 2772 or whatever fits your needs.

Once this is done, any files added to the directory will automatically change to group afp.

[SteveRiley]

Great guide, Oshun. Stickying.

[kubicle]

One additional note, though:

You only need sgid for directories (not files) for inheritance to work...I'd generally be cautious to set sgid on files, (executable) files would run with effective GID "afp" if sgid is set on them (not necessarily a security hole in this case, but general caution is advised when using sgid on executables...sgid means different things when set on directories as opposed to files)

[oshunluvr]

Good point, kubicle.