Sharing a system - Servers Administration, Networking, & Virtualization
(This is part of the podcast discussion extension)
Sharing a system
Link of the recording [ https://raw.githubusercontent.com/nixers...-05-01.mp3 ]
Resources, services, checking access, and security; making sure everything is right.
-- ( Show Notes )
That's a pretty new topic for me.
I've been setting up a shared box for development purposes. I went for the simplest setup possible, which required three "features":
The first thing to do was to create a group for everyone. Let's say "devs". Once the group is set up, you can create a "work place" for everyone.
I'm still not sure where such a place should be on a linux system... I chose /ns/$PROJECT, "ns" meaning "namespace" here. But I don't think there is a POSIX or even FHS compliant place for such a thing.
Once the directory exist, there are two things one can do. First, I set the group owner to "devs", and make the group sticky, so that every inode created under this directory will inherit the group:
Of course, this lacks write permissions for the group, but instead of using the traditionnal Unix permissions, we'll use the POSIX ACL (access control list) to finer tune the access. Beware, not all filesystems support ACLs.
One "limitation" of the unix permissionning system is that you can't make subfolders or files "inherit" the permissions from their parents. New files/directories will have the permissions set by the umask. And sadly, it's named 'umask', not 'gmask'. One could "force" the users of the "devs" group to use umask "002" but it's far from efficient, as the users can easily override it and mess up your project.
POSIX ACLs permit that:
Both notations are the same. This will set the "default" permissions on the "group" field to "devs" with "read + write" access to the /ns/$PROJECT directory, and all its subtree. Because "rw" is the default doesn't mean it's limited to this permission. You can still change the permissions with "chmod", or even use "setfacl" against a specific subfolder.
Hey z3bra I like your namespace /ns/<PROJECT> concept. I do believe that this is the way to go.
Yes, sadly umask is pretty limited and the access control of chmod/chowm is very limited.
There is more information about ACLs in here: https://wiki.archlinux.org/index.php/Acc...trol_Lists
I believe these ACLs are important when it comes to security, since they allow for a more dynamic approach. (Inheritance)
They do however bring risks, in such that if the parent changes all subdirectories and files will also be changed (And possibly unreadable by someone).
I suggest you use https://wiki.archlinux.org/index.php/Fil...and_lsattr chattr in order to lock the attributes of your specific namespacae after making sure your permissions are correctly set up! :)