Re: completeness of the upg tests
On Sat, May 29, 2010 at 12:34:38PM +0200, C. Gatzemeier wrote:
>
> Thank you Harald for scrutinizing.
>
> Am Fri, 28 May 2010 14:50:27 +0200
> schrieb Harald Braumann:
>
> 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.
ACK
> 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.
ACK
>
> > 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.
ACK
> 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.
ACK
> 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.)
ACK
> 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)
I don't, and that is what I meant by wishful thinking. Nowhere is it
guaranteed that it works this way. Even if there where guarantees by
POSIX, which I'm not aware of, you could as well authenticate against
an Active Directory or a Lotus Domino Directory exported as an LDAP
tree or some directory that is managed by homegrown scripts. Does it
work that way there?
pam-umask's usergroups options does the right thing in many cases. But
only the admin can know if the user database conforms to the necessary
critera. And in that case, he can enable it and use it for automatic
umask relaxation. But it shouldn't be the default if you can't
guarantee that it works in all cases, and you can't.
Yes, it is a slight inconvenience that you have to explicitely enable
it for the many systems where it will work. But that is very often the
case: that you trade convenience for security. It always depends on
your priorities. If your priority is convenience, you will
use auto-detection. If your priority is security, you will keep 022 as
default umask and don't use auto-detection on default.
Cheers,
harry
Reply to: