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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531101754.gb4...@sbs288.lan
