[NCLUG] Why one group per user and SGID home dirs

[Matt Taggart]

"S. Luke Jones" writes...

> I generally agree with Mike. Users should be taught to manage their own
> permissions and 'umask' can backstop them until they figure out what
> they're doing.

I think this is a case where the dafault makes it easier for people who know 
what they're doing and confusing(but safe) for newbies.

> Here's a question for you experienced Bof###system admins: how do you
> structure directories to accomodate multi-user projects? Let's say that
> users Alan, Bob, and Charlie are all part of the Foobar team. You make
> a group "foobar" and add them all to it, yes? Then you need to find a
> spot in the filesystem for them to share: do you coach "alan" about how
> to make a navigable path (setting g+rx on directories, etc.) to some
> directory he manages, or do you make a new directory somewhere else.
> If the latter, where?

As I mentioned in a previous mail some projects are big enough to warrant the 
BOFH creating a separate dir, some are small enough that a user should be 
expected to set something up in a dir they already control. I think it's a 
trade off between the amount of work for the BOFH and how clean and orderly 
they want to keep the filesystem. I suspect you'll get different answers from 
every admin as everyone has their own opinion about such things.

> What I do (for all my users :-) is create a new user "foobar" and let
> RedHat's useradd policy create a group and the /home/foobar directory.
> Then I make ~foobar group accessible (chmod g+rwx ~foobar) and lock
> the account so nobody can login as foobar. Finally, I add Alan, Bob,
> and Charlie to the group "foobar".

Sounds like an ok policy to me. Some people might complain about having an 
extra user but as long as they don't have a shell then I don't see much harm. 
You could also assign project files that have no clear owner to that user if 
users are concerned about owning the files or are under quota restrictions.

> I'd appreciate any suggestions for improving this scheme.

The only thing I can think of is to invoke adduser as,

adduser --disabled-password  --home=/project/foo foo 

instead so it's clear that it's a "project" type user and the password 
disabled. Then do a,

chsh -s /bin/false foo

so there's no chance of people using the account.

-- 
Matt Taggart
matt at lackof.org