Re: UPG and the default umask
-----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 <Klaus@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-----
Reply to: