Re: The story behind UPG and umask.
Am Tue, 25 May 2010 22:47:51 +0200
schrieb Harald Braumann <harry@unheit.net>:
> On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
>
> > The
> > path into your home directory is not restricted, just as the path
> > others can take to ring your bell at home is not restricted.
>
> Depends on adduser settings. Both, world readable and private home
> directories are common.
Thanks! Adding ...the path to your home *is by default* not
restricted,... seems to be more precise.
>
> > All this can work because the primary group of each user is set to a
> > private user group (UPG) by default.
>
> This is a bold assumption. In a system where user management is
> external (e.g. LDAP), anything is possible and there are no defaults.
We were just stating different assumptions, yes. Maybe also
adding ...this can work in a default installation because...?
>
> > According to [1,2] a UPG is identifiable by
>
> This is wrong. There is no way to differentiate UPG - non-UPG. But I'm
> repeating myself ...
I've gone though your related posts that I found on the web. (Wasn't
subscribed before, so answering here.)
OK, the definitionn is wrong, or not complete, in the sense that it does
not catch all possible UPGs.
The auto-umask adjusing feature won't work for all possible UPG
implementations, but it should work safely for the default debian
installation, without compromising security in other environments.
So yes, you can setup UPGs with UID!=GID, but then you'll also
have to set the umask manually to make it work (globally or in gecos or
ldap etc.).
The UID==GID and username==groupname restriction of the
pam_umask's "usergroups" option ensures that the umask is only relaxed
automatically in very specific defined cases.
That's why I'am thinking the UID==GID restriction pam_umask makes (and
login made before) can be sane choice. (Others seem to use it also,
and it is upstream.)
The mentioned three points of the current implementation I found on the
web even allow intentional addititions of users to the UPG as a quick
way to set up trusted (sub-)users without requiring extra groups and
groupdirs to work with files in your sub-user's account. And it allows
proper removal of a UPG together with the user, if it is unused.
> Let me quote from the comments in /etc/login.defs:
>
> #UMASK 022 is the "historical" value in Debian for UMASK when it was
> used
Right, that UMASK value was commented out when it needed to be
dispersed into shell rc files, due to PAM not supporting "usergroups"
yet.
And below that comes "USERGROUPS_ENAB yes" which also
"historicaly" did adjust the umask for UPG users.
Of course we agree that UPGs and all related automatic umask adjustment
should be configurable, i.e. they can be disabled.
Cheers,
Christian
Reply to: