Add support for supplementary groups

[brianhlin]

We noticed an issue with support for group-owned directories where the setfsgid call appears to only get the primary group of the user (frequently the user-specific group, e.g. brianhlin). This is not particularly useful for shared FS access of a dir tree so we'd like to see support added for supplementary groups, perhaps by using getgrouplist and setgroups in addition to the the set UID/GID calls.

We should also consider moving to setuid and setgid (or maybe seteuid/setegid?) as setfs*id says:

Since Linux 2.0, signal permission handling is dif‐
ferent (see kill(2)), with the result that a process can change its ef‐
fective  user ID without being vulnerable to receiving signals from un‐
wanted processes.  Thus, setfsuid() is nowadays unneeded and should  be
avoided in new applications (likewise for setfsgid(2)).

[bbockelm]

@brianhlin - what do you propose be done for supplementary groups though? How should we decide which one is used in creating the directory?

also, the man page advice is not particularly helpful. seteuid works at the process level (all threads) while setfsuid works at the thread level. setfsuid is one of those calls that’s deprecated for decades but without a clear replacement for this use case IIRC.

[brianhlin]

I know @juztas was interested in a solution here, too. To work around this problem we did the following:

1. Created the directory with the setgid bit with the group owner set to the relevant group
2. Made the dir world-executable
3. Set multiuser.umask 007 so that when writing to the dir, XRootD won't create any world-readable files

(2) and (3) aren't great if the user has POSIX access as they may accidentally create world-readable files.

I think (1) is a reasonable requirement to have. So as @matyasselmeci smartly pointed out, the real problem appears to be directory traversal. Maybe something silly like setting setfsgid to the GID owning the target directory?

[bbockelm]

I mean, the right way to do this is to emulate how supplementary groups work. Maintain a timed-limited cache of the supplementary groups per user, open the parent directory when creating files, and then emulate the Linux directory creation logic.

Similarly with opening files, we'd need to walk up the directory tree, checking permission at each step. Not impossible ... but certainly a lot more complicated than what we have today.