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. You can always add users to additional groups and use setgid directories. There is really no need to make some users non-UPG. So I don't think this needs to be supported out of the box. > I think for an inappropriate relaxations to occur, the user/group info > would have to come from some external system. And that is exactly the problem. If users are managed locally, you don't need any fancy auto-detection, because you know the system is UPG. The default for USERGROUPS is yes in /etc/adduser.conf. If the admin changes this, you can also expect him to change the default umask. But 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. 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. 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. So one thing is the change of the default value. I'd say keep the default at the most secure value. But the world won't end if it is changed. You just shouldn't forget to change it if you change USERGROUPS to no or use external user management. 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. 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/20100528125026.ga4...@sbs288.lan
