completeness of the upg tests (was: test if primary group, with only implicit membership of the user?)
Thank you Harald for scrutinizing.
Am Fri, 28 May 2010 14:50:27 +0200
schrieb Harald Braumann:
> On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote:
> > 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.
>
> Why would you create such a mixed system? I don't see a usecase for
> that. If the system is UPG it should be UPG for everyone.
Ideally yes. However we have to consider that non-upg users can be
preexisting (system users even) or get imported somehow. But more
importantly people can get into this situation simply by changing
the adduser/useradd's UPG setting after some users have been created.
> if users are managed externally, then nothing is
> guaranteed. All the assumptions about name or id equalities are
> nothing more than that: assumption.
>
> Therefore this autodetection will fail for all systems that don't
> conform to pam-umask's idea about user and group set-up.
If that externel system means to have UPGs, but does not support
propper ID allignment (like debian, at least in the last releases), one
will have to fix it or set a fixed umask, yes.
Same can be true in cases where a custom site-wide UPG user database is
used. In this case, exactly as you wrote, manually setting a
default umask is an option, if the IDs are not alligned or the user is
explicitly added to his primary group.
> And in those
> cases where it fails, I'd expect it to fail only for specific cases
> that might go unnoticed for a long time and might be hard to analyse.
It's probably better if these are cases where the umask hasn't been
relaxed, than cases where a fixed 002 umask is to permissive. This is a
case for the 022 default with "usergroups" relaxation.
Then if one has UPGs, but notices the umask is not 002 for some
users, one checks login.defs and is informed about the checks and given
a way to set a fixed umask.
However in case the external System properly supports alligned IDs (RH,
etc.) I currently don't see where any rare cases of misbehaviour in
either way should come from. The tests should work equally well even
with "mixed usersgroups". Just like on the external system itself.
If the external user database is non-UPG, this is the case where the
tests prove most useful and provide security over setting a system wide
002 umask as a default. (Additionally it is a case where the admin can
choose to turn umask relaxation off for peace of mind.)
To shield against any cases of username==groupname (say a "vip" user
and group, or any other case of matching initials) where only
coincidently UID==GUID match, I asked to check if "vip" is the primary
group of the "vip" user and "vip" user is not an explicit member of the
"vip" group.
I believe this completes the checks (see below), while it supports user
private groups that consist of multiple members. An example can be
family members that can be fully trusted and one wants to give access to
almost everything in $HOME (which should not be a sgid directory), or
abstract sub-users (used by programs) like "accounting" which data is
accessable by members of the accounting department.
> So anyone with some conscience for security will immediately disable
> this source of indeterminism and set the umask to a fixed value. I
> know I will.
That is OK, by rather setting a system wide fixed 002 umask you can be
sure users authenticating against an external system will get a umask
that can be too permissive. It may still make sense, as you have more
knowledge/control about the local environment than the debian system.
> So one thing is the change of the default value.
Debian delivers a UPG scheme, and to deliver it functional umask
002 is required. But setting 002 as a _global_default_ is too
much. That's why the default umask stayed 022 when UPGs where
introduced in distros, and is only relaxed conditionally.
> I'd say keep the
> default at the most secure value. But the world won't end if it is
> changed.
Supporting the UPG features with a system wide umask would IMHO be a bad
idea. Even if the admin may allways think of changing it, a fixed
umask won't cut it for "mixed systems" where some (system) users do not
have UPGs.
> But the other thing
> is this auto detection that is only based on wishful thinking and just
> adds complexity and indeterminism. I'd really rather Debian wouldn't
> do this.
Then we just see things differently here, I would consider it wishful
thinking to rely on admins to be able to manually set the correct
umask for all individual users in all cases, and consider the rather
simple alignment and testing rules to be fully deterministic. What's
missing is just a test that completes set of tests.
Testing for an empty primary group will however reduce the UPG usage
scheme to not support shared $HOME access.
Testing for a primary group with only implicit membership of the user
group OTOH allows for multi member private groups.
The latter should also complete the tests, because a mismatch
possibility is first reduced to a singular case per group, where on an
non-UPG system a group "$USER" and user "$USER" is created (with same
IDs, so the database had most probably to be empty before) and the
group is only set as primary group to the user (instead of regularily
adding $USER to the $USER group). Every other user in the $USER group
will have a different user name and ID.
And this singular case will never happen on non-UPG systems
that correctly and consistently add/list users as group members if
they are added to a group. (If a non-UPG system does not report a user
to be in his primary group, that can be considered a bug in that
system.)
Anybody who sees corner cases please show them.
Cheers,
Christian
Reply to: