Am Mon, 31 May 2010 12:17:54 +0200 schrieb Harald Braumann: > > 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.
Could you please be a little more specific and try to provide a counter example to the reasoning I included in that other message? So we can see what you mean. > 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. So do we know that pam_umask usergroups is perfectly safe with the debian default user database? Isn't what we are discussing here only whether (if an admin changes the debian default to another user database) a relaxation may occur unjustified or not? Umask relaxation should be 100% safe with the debian default user database and settings. So the conditional relaxation can stay enabled by default. (As it was from the beginning. The functionality is only now available again with pam_umask.) We all agree a fixed 002 umask is not good, and that change should just be reverted as soon as possible. But in cases where an admin changes the database to a non-default one, it is perfectly fine for him to also have to turn umask relaxation off to make things work, if the user database does not conform to the common criteria. No matter if that means setting a fixed "abc" or "aac" umask in the resulting system. IMHO umask relaxation can be enabled by default in debian, even if there is an example where the umask would get relaxed unjustified with some non-default non-debian or even rogue user data base. It's just that all the legitimate examples I could come up with, won't get an unjustified relaxed umask anyway with the completed tests. 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/20100531154435.43367925c.gatzeme...@tu-bs.de@tu-bs.de
