Sharing a system

Sharing a system - Servers Administration, Networking, & Virtualization

Users browsing this thread: 2 Guest(s)

	venam Offline \| 23-05-2016, 02:02 AM \| #1

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

Administrating users
Access rights
Virtualization
Services
Security
Bonus points

-- ( Show Notes )

https://wiki.archlinux.org/index.php/Multi-pointer_X
https://wiki.archlinux.org/index.php/Xorg_multiseat

	z3bra Offline \| 24-05-2016, 10:46 AM \| #2

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":

/etc/group
POSIX ACLs
chmod's sticky bit

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:

Code:
mkdir -p /ns/$PROJECT

chgrp devs /ns/$PROJECT

chmod g+s /ns/$PROJECT

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:

Code:
setfacl -m 'default:group:devs:rw' /ns/$PROJECT

setfacl -m 'd:g:devs:rw' /ns/$PROJECT

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.

	TheAnachron Offline \| 09-09-2016, 04:46 AM \| #3

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! :)

View a Printable Version