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 -- 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/20100529123438.42394506c.gatzeme...@tu-bs.de@tu-bs.de