Re: test if primary group, with only implicit membership of the user?

["C. Gatzemeier" <c.gatzemeier@tu-bs.de>]

Am Fri, 28 May 2010 08:37:05 +0100
schrieb Roger Leigh:

> Calling getgrgid/getgrnam and
> checking that the user list is empty is *ensuring* that it's private,
> at least at the point in time we check (we can't predict the future).
> 
> This check would protect against adding other users to UPGs,

Yes, if we'd check for an empty user list, that would break the
"sub-users" feature. Say if "me" wants to run iceweasel under the
user "me-iceweasel", you can simply "adduser me me-iceweasel" without
breaking the UPGs scheme (in contrary, benefitting from it when
working with sub-user files, because me-iceweasel can still get umask
002) while not having to set a fixed relaxed umask.

If there are other users in the users' private group, IMHO we just
can and should assume they are there intentionally. So the test 
may only look for the fact that the user is _itself_ not an explicit
member of his primary group. That would not be the case if the
group was created as a regular group for collaboration (like the "users"
group, or any other) and users are added to it.



> at least 
> from the POV of not relaxing the umask (it's still a bad idea).

I'm not sure yet, if I do properly understand the point when/why
relaxing conditionally is a bad idea. To me, setting *fixed* umasks with
group permissions equaling user permissions seems worse,
especially because not all users of a system need to be set up with
UPGs.

I think for an inappropriate relaxations to occur, the user/group info
would have to come from some external system. If we test
username==groupname, and GUID==UID (it seems to be a standard among
UPG systems to allocate cleanly alligned group IDs) and if we can add
to this the test if the user is not an explicit member of his primary
group (for all db backends?) that looks like a pretty firm while
flexible test to me.

It's only unfortunate that debian's "useradd", that it does not
allays allign IDs, hasn't been seen as such earlier, but it is on its
way to be solved.

Kind regards,
Christian