[SOLVED] Linux folder Group/User permissions

RexDeus9 · 12-21-2017, 08:30 AM

Hi,

Sorry if this is too simple for a Linux expert, but I need some clarifications.

- Here's the need:
Create a folder for the HR department that will permit the HR team to create/modify/delete any folder/files within the hierarchy of that folder.

- Here's what's been done:
1.- Create "/shared/HR" folder
2.- Create HR group "HRTeam"
3.- Add HR users to the "HRTeam" group
4.- Set folder owner: chown -R <admin>:HRTeam /shared/HR
5.- Set permissions: chmod -R u+rwx,g+rwx,o-rwx /shared/HR

- Here's the issue:
1.- HR user Jane Doe (jdoe) creates a file and has this listing:
-rw-r--r--. jdoe users 26024 Dec 21 08:12 CA_Cities.xlsx

2.- Even if the file was created by an HRTeam member, nobody else in the HRTeam can read/modify/delete that file

What am I doing wrong?

_roman_ · 12-21-2017, 08:40 AM

https://wiki.archlinux.org/index.php...and_attributes

Quote:

To come up with a 3-digit number you need to consider what permissions you want owner, group, and user to have, and then total their values up. For example, if you want to grant the owner of a directory read write and execution permissions, and you want group and everyone else to have just read and execute permissions, you would come up with the numerical values like so:

Owner: rwx=4+2+1=7
Group: r-x=4+0+1=5
Other: r-x=4+0+1=5

the reason why chmod exists

Quote:

1.- HR user Jane Doe (jdoe) creates a file and has this listing:
-rw-r--r--. jdoe users 26024 Dec 21 08:12 CA_Cities.xlsx

2.- Even if the file was created by an HRTeam member, nobody else in the HRTeam can read/modify/delete that file

you have the read flag set on group and others also read.

--

maybe try first chmod 770 file

edit: I love the arch linux wiki

# chattr +i /path/to/file
That way I could fix the gentoo dhcpcd bug. Or my laziness and think i know better how things should work.

when you use chattr +i you will have certain issue on that file. no stupid system deamon (gentoo developer developed dhcpcd) can nuke it. off topic: dhcpcd does not respect the old design how network should behave. I only talk about the gentoo shipped ebuild.

rnturn · 12-24-2017, 11:16 AM

Quote:

Originally Posted by RexDeus9

Hi,

Sorry if this is too simple for a Linux expert, but I need some clarifications.

- Here's the need:
Create a folder for the HR department that will permit the HR team to create/modify/delete any folder/files within the hierarchy of that folder.

My initial approach would be something like:

Code:

find /shared/HR -type d -exec chmod g=rwx {} \;
find /shared/HR -type f -exec chmod g+rw {} \;
chgrp -R hr /shared/HR
chmod -R g+s /shared/HR

The last command makes each new object created in the directory tree owned by the "hr" group.

Create a group--using whatever user management tool you have--called "hr" and add each HR user (say: sue, linda, nick) to that group. When you're done you should see something like:

Code:

$ grep hr /etc/group
hr:x:1003:sue,linda,nick

Finally, and this is important, the user mask for each of those users needs to something other than the default of "022". I've used

Code:

umask 002

for users that need read/write access to a development tree. Put this in their profile (~/.bashrc or whatever). I put it near the end of the profile. Without changing the umask, newly created files and directories will be owned by the individual users, granted read/write access to that user, but the group access will still be read--no write access--so other users will encounter "odd" permission errors depending on what they're trying to do. Just set the umask to avoid these.

This is a pretty simple access control mechanism. For more complex controls ("sue" and "linda" can edit /shared/HR/payroll files but "nick" can only read, etc.), you'll find yourself looking into access control lists (ACLs). For a little "light" reading, try "man setfacl" and "man getfacl".

Hope this helped.

Later... (I'm off to enjoy the holiday.)

jlinkels · 12-24-2017, 12:02 PM

The problem with changing the umask is that all files created by a user will be 775. I find that often undesirable.

I though the correct solution is to put the setgid bit on the shared/HR directory. IF someone has permissions to write in this directory, all files will automatically bear the permissions of the parent directory. And all files will be owned by the HR group.

So, once shared/HR has: drwxrwsr--, all files below it will have -rwxrwxr--.

And the command to do this is:

Code:

chmod g+s shared/HR

The longer explanation here: https://superuser.com/questions/2777...g-to-the-group

jlinkels

rknichols · 12-24-2017, 12:56 PM

Quote:

Originally Posted by jlinkels

The problem with changing the umask is that all files created by a user will be 775. I find that often undesirable.

I though the correct solution is to put the setgid bit on the shared/HR directory. IF someone has permissions to write in this directory, all files will automatically bear the permissions of the parent directory. And all files will be owned by the HR group.

So, once shared/HR has: drwxrwsr--, all files below it will have -rwxrwxr--.

Did you test that? Sorry, but the setgid bit on the directory causes new files to inherit the just GID of the directory, not the group permissions.

The entire reason for the change to assigning a unique primary GID per user (as opposed to the eariler convention of putting all users in a group called "users") is to allow users to safely open up their umask to allow group access. That allows a group-shared directory to give full read/write access to files. If you don't want to do that, the alternative is to set a directory's default ACL to allow access to files. That default ACL is inherited by newly created files.

jlinkels · 12-24-2017, 01:55 PM

Quote:

Originally Posted by rknichols

Did you test that? Sorry, but the setgid bit on the directory causes new files to inherit the just GID of the directory, not the group permissions.

Your version is correct. The GID will be set correctly but the user still has to set his umask correctly.

jlinkels

rhubarbdog · 12-24-2017, 06:36 PM

A shared network i used to use corrected prrmisions and ownership with a cron job running every minute or 2 in a shell script just have code

Code:

chown -R <admin>:HRdept /home/HRfolder

rnturn · 12-24-2017, 09:18 PM

Quote:

Originally Posted by jlinkels

The problem with changing the umask is that all files created by a user will be 775. I find that often undesirable.

I though the correct solution is to put the setgid bit on the shared/HR directory. IF someone has permissions to write in this directory, all files will automatically bear the permissions of the parent directory. And all files will be owned by the HR group.

So, once shared/HR has: drwxrwsr--, all files below it will have -rwxrwxr--.

And the command to do this is:

Code:

chmod g+s shared/HR

The longer explanation here: https://superuser.com/questions/2777...g-to-the-group

jlinkels

In my reply, I DO set the gid bit in the parent directory. Files created in the directory don't always get the group write permission--it depends on the umask setting of the user creating the file. At least that's how it's behaving on OpenSuse. The only sure fire way I've run across to ensure permissions are set be default in the scenario w/o tweaking each user's umask in the original post is using ACLs (setfacl -d ...). You really have to dive into ACLs and get used to how they behave or it can be confusing.

(In a former life, there were cases where we used to control access to files/directories on VMS by setting the normal file/directory permissions to none for everyone; all access was through ACLs and rights identifiers. Blew user's minds.)