-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
Am Di den 11. Mai 2010 um 17:13 schrieb Aaron Toponce: > > You can never trust anybody for giving him rights to _all_ of your > > files. So this assuming is never true and a user will not have any > > benefit of this group if the umask is 002! > > I trust my wife to all of my files. Good. :-) > >> If you don't trust users in your UPG, then the administrator should > >> setup a different group, and put the necessary users in that group. > > > > Give me one case where this is true. If there is a group for sharing > > purpose the users will use it -- and will lower there security down to > > nothing. Setting a default umask of 002 is highly negligent! > > We have a 'weblogic' group where many user accounts are added, so they > cane manipulate webolgic domains and configurations. Would you like more > examples? That was not the point. That you can use other groups for different purposes might be clear. The point here is about the UPG itself. So group foo for user foo. And this is the dangerous point. > > Thats true. But setting the umask to 002 will lower them for no benefit. > > I've told you how making the umask '0002' increases collaboration for > development teams. If you need such collaboration stuff you are welcome to set it up on your system. There is not that much more work in telling the users that they have to change there umask when collaborating. However, you have to do that step in any case as there are many users setting they own umask in a startup script. > And it doesn't change the security of files that has your UPG as the > group of your files/dirs. Everyone not you, or a member of your UPG > still falls under the 'other' permissions, And that is exactly the point. The only advantage of a UPG is to give other users a bit more rights than other. So you add them into your own group. With umask of 022 that will do no harm. With umask of 027 that is a real improvement. But with the umask of 002 that is very very dangerous! And adding this danger only to set a default for the special case of collaboration stuff where you have to tell the users anyway to set there umask, is a bit to much collateral damage! > so for the sake of security, you might as well change it to '0007'. That was not the point. And I show you how to use the UPG usefull with setting the umask to 027. > My argument is about the group permission, not other. Right, mine too. > > The crazy idea of setting the umask to 002 per default will end in many, > > many systems where the users have a low as nothing security for they > > important files only to serve some few use cases where the persons > > normally know how to get rid of anyway. > > Explain the security implications of '0002'. Your home directory will be > 'drwxrwxr-x foo foo', so anyone who is not user 'foo' or in the UPG > 'foo' won't be able to modify a thing. If you're concerned about them > viewing the files, then '0007' would give 'drwxrwx--- foo foo'. Setting > the write bit on the group doesn't change any security mechanism for the > user 'foo' or his UPG 'foo'. As long as the user do not use his UPG at all. And in that case the UPGs are useless at all. Any use case involving the UPG would suffer from a umask of 002. > If you're concerned about a developer in a collaboration group doing > something nasty, then they shouldn't be on the team. Otherwise, remove > them from the group, restore from backup, and carry on. Collaboration groups are a very special use case of POSIX group design. There is no UPG involved. > It's easy to say "in the name of security", without really thinking > about what you're advocating. It is easy to break security when not thinking what collateral damage a change will do. I think I made the point very clear above. > Updating the umask value to allow the write bit on groups when UPG is > setup (as it is by default) just makes sense. In the most cases, no, no, no! Only in a very few use cases that might make sense. > Keeping the write bit off the group, means we're too lazy to change > old historical baggage. Aha. Maybe the whole bunch of security is historical baggage we learned in the past. Just throw it away as it is historical baggage. Did you even think about other use cases than the very special one of collaboration directories? (Sorry to tell this question but I am really in doubt if you understand the point I talked about.) Regards Klaus - -- Klaus Ethgen http://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <kl...@ethgen.de> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBS+mLsJ+OKpjRpO3lAQqJDwf/ShMklFffEpFO75hXgVnNtXqbPTuMhhft I74bONZMhCP8ATZ/25SZAUWfif93cGtxNztwKU7KRBe5cPyHuSODBK4slyPXeNG9 9AC+8PLAWkp//LCxX4Oq0I/XcD3MlVdoiZl+0JRoEB8bxK8KFf6nt8IXz1GXzrCG //b7jSZ2vfevrBvby5VVyBsnXDoYM74nXxmqUQok8ub+nBfGmWoUJzlxP9z+xCsp q9VUkQKqft69OJ0bE92PPq595yAYzf3tlzt+bkQ7Mz4+0UixhT/84ZK2m6TQ4mn1 HuKiunQ1ywdbXxl/TXEMCSYB2J3E3pG24u421Iglb1MwPLggLrPB1w== =QgJC -----END PGP SIGNATURE----- -- 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/20100511165408.ge9...@ikki.ethgen.de
