On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote: > Willi Mann <foss...@wm1.at> writes: > > Russ Allbery wrote: > > >> The purpose of UPG is not to use the user private group for any sort of > >> access control. Rather, the point is to put each user in a group where > >> they're the only member so that they can safely use a default umask of > >> 002 without giving someone else write access to all their files. > > > Is it possible to detect whether an account is configured properly based > > on the UPG idea? If yes, wouldn't it then make sense to only set umask > > 002 if a proper UPG account is detected, otherwise 022? This would avoid > > putting non-UPG systems on danger. > > That's a good idea. I'm not sure if all UNIX group systems allow one to > ask how many users are a member of a particular group, but if there's a > way to ask that question at least in those group systems that support it, > the implementation should be fairly straightforward.
To me this sounds more like heavy wizardry. Given the flexibility of pam this can at best be heuristical. Also it would change the umask from being a fixed value to being a dynamic value based upon some arbitrary global state. This would increase complexity and make it harder to reason about the system. Such changes should be avoided if there isn't a really good reason. And to make collaboration easier isn't a convincing reason, beacause the admin can easily change the default umask, already, if needed. I don't see a security problem with a umask of 002 in a UPG system and I also agree that it would be preferable in such a system. But the possibility of non-UPG systems is a valid concern. Therefore I'd opt to keep a default umask of 022. And don't try to be too clever figuring out what the umask should be. Keep it simple and let the admin decide on this. So on a system where collaboration should be supported, and the admin knows that it's a UPG system, he can set the umask to 002. It's not as if this was an overly complex task. 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/20100516105939.ga4...@sbs288.lan
