UPG and the default umask
Aaron Toponce
means that when a new user is created on a system, a group of the same
name, if not already in place, is created, and the user is placed in the
group, as the only user. Thus, when new files (dirs, etc) are created by
that user, the group added to that new file is the UPG of the user.
For example:
# useradd foo
# id foo
uid=1000(foo) gid=1000(foo) groups=1000(foo) [snip]
# su - foo
$ touch newfile
$ ls -l newfile
-rw-r--r-- 1 foo foo 0 May 10 10:05 newfile
So, the appropriate group is applied, and the user foo is the only
member of the foo group. But, do you see a problem? The group
permissions are 'r--', even though 'foo' is the only member of the 'foo'
group. This means the umask is '0022'. If we change the default umask to
'0002', then the appropriate permissions will be applied with the group:
$ umask 0002
$ touch anotherfile
$ ls -l anotherfile
-rw-rw-r-- 1 foo foo 0 May 10 10:06 anotherfile
As it sits, having the default umask set as '0022' isn't breaking
anything, but it's no longer needed. It's just historical baggage coming
from the 'users' group on older UNIX systems, where any new user added
to the system was added to the 'users' group by default. Thus, removing
the write bit made sense. It doesn't make any sense with UPG.
For comparison's sake, Fedora (and as a result, RHEL/CentOS/etc) have
implemented '0002' as their default umask, as they implement UPG.
openSUSE and family, however, still use the 'users' group, so it makes
sense for them to use '0022' for their value.
I guess I'm more or less curious why we're still using this outdated
umask value with UPG. What would it take for Debian to update our
default umask to match the UPG scheme? Is this doable for Sqeeze? Are
there reasons for not making the switch?
Thanks,
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
Julien Cristau
> I guess I'm more or less curious why we're still using this outdated
> umask value with UPG. What would it take for Debian to update our
> default umask to match the UPG scheme? Is this doable for Sqeeze? Are
> there reasons for not making the switch?
>
Are there reasons for making the switch? With user groups, umask 002 or
022 doesn't make a difference. To switch off user groups, you set
USERGROUPS=no in adduser.conf, and that's it.
Cheers,
Julien
Aaron Toponce
The biggest reason for making the change is when group collaboration
becomes a necessity. Suppose you have an 'devel' group on the system,
and a central directory where the collaboration happens. Because of the
default umask value being '0022', the users must make sure that they
have 'umask 0002' in their shell rc file, or as appropriate, or they
must be constantly calling chmod to change the group permissions when
new files are created. If the default umask is '0002' on a UPG system,
then this checklist item doesn't need to be worried about.
For example:
$ id
uid=1000(foo) gid=1000(foo) groups=1000(foo) [snip]
$ mkdir src
$ ls -ld src
drwxr-xr-x 45 foo foo 4096 May 10 10:36 src/
$ chgrp devel src
$ ls -ld src
drwxr-xr-x 45 foo devel 4096 May 10 10:36 src/
$ chmod g+ws src
$ ls -ld src
drwxrwsr-x 45 foo devel 4096 May 10 10:36 src/
$ cd src
$ touch foo.c
$ ls -l foo.c
-rw-r--r-- 45 foo devel 4096 May 10 10:36 foo.c
$ chmod g+w foo.c
etc.
Again, this headache can be eliminated by setting the umask to '0002' in
their .bashrc, .profile, etc, or it could just be set it system-wide,
seeing as though we're implementing UPG from the outset.
In my professional experience, I've seen cron jobs setup to navigate to
a development directory, and 'chmod -R g+w *' to make sure the write bit
is set, which is rather pathetic (and inappropriate) if you ask me.
Drake Wilson
> On 5/10/2010 10:23 AM, Julien Cristau wrote:
> > On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote:
> > Are there reasons for making the switch? With user groups, umask 002 or
> > 022 doesn't make a difference. To switch off user groups, you set
> > USERGROUPS=no in adduser.conf, and that's it.
>
> The biggest reason for making the change is when group collaboration
> becomes a necessity.
FWIW (which is probably vanishingly little), I find that dealing with
significant group or even inter-user interactions on Unix machines
eventually gets nearly impossible in the absence of full POSIX ACL
support. Modern Debian supports this well with a suitable filesystem
on the backend, though depending on your interop requirements there
may be other problems.
In this case, the umask problem you mention:
> Suppose you have an 'devel' group on the system,
> and a central directory where the collaboration happens. Because of the
> default umask value being '0022', the users must make sure that they
> have 'umask 0002' in their shell rc file, or as appropriate, [...]
goes away almost entirely if you [setfacl -m d:g::rwx] (or d:g::rx,
whichever is appropriate) the central directory. (This still doesn't
catch mv'd files, but neither does umask, and that's sort of another
kettle of fish.)
I regularly set my personal umask to 0077 because I find accidentally
creating files that other users can snoop on to be more dangerous than
having to chmod files after the fact. Conversely, setting default
ACLs is one of the first things I do when setting up collaboration
directories.
---> Drake Wilson
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100510172...@drache.begriffli.ch
Aaron Toponce
> FWIW (which is probably vanishingly little), I find that dealing with
> significant group or even inter-user interactions on Unix machines
> eventually gets nearly impossible in the absence of full POSIX ACL
> support. Modern Debian supports this well with a suitable filesystem
> on the backend, though depending on your interop requirements there
> may be other problems.
I have no problems with FACLs, except they add to added complexity and
administration to the filesystem. They're difficult to maintain when
multiple groups and users are involved. When scattered about the
filesystem, it's not trivial to remove ACL permissions when users or
groups are removed from the system. Making the default umask '0002'
system-wide on a base install, however, is extremely trivial. Having the
administrator then set FACLs as appropriate can be at their discretion
without getting in the way.
> I regularly set my personal umask to 0077 because I find accidentally
> creating files that other users can snoop on to be more dangerous than
> having to chmod files after the fact. Conversely, setting default
> ACLs is one of the first things I do when setting up collaboration
> directories.
FACLs on collaborative project directories and files is almost a
necessity, and I understand the security of changing your umask to
something more tight on multi-user systems. And if the umask switches
the other direction to '0077' in the name of security, I don't see any
problems there. However, leaving it at '0022' is just historical
baggage, and there's no good reason to leave it there.
Klaus Ethgen
Hash: SHA512
Am Mo den 10. Mai 2010 um 17:14 schrieb Aaron Toponce:
> $ umask 0002
> $ touch anotherfile
> $ ls -l anotherfile
> -rw-rw-r-- 1 foo foo 0 May 10 10:06 anotherfile
>
> As it sits, having the default umask set as '0022' isn't breaking
> anything, but it's no longer needed. It's just historical baggage coming
> from the 'users' group on older UNIX systems, where any new user added
> to the system was added to the 'users' group by default. Thus, removing
> the write bit made sense. It doesn't make any sense with UPG.
I still makes sense. The user will not win with the lazier umask but he
will probably loose security.
See the case the user wants another person in his own group to share
files. Then he might set the files readable for his group only but not
for world. So the other user can read this data. But he cannot write it
as it might be intended.
Setting the umask to 002 let the other user _edit_ all files the user
did create in the past with that umask factual giving away most of his
files.
The better Idea would be to set the user mask to 027 which then add a
new value of security.
If a user want the group to have write permissions this should be set
explicit. By the way, with zsh you can make directory profiles which
set the umask depending on the directory.
> For comparison's sake, Fedora (and as a result, RHEL/CentOS/etc) have
> implemented '0002' as their default umask, as they implement UPG.
Yes. And that is one big security issue!
> I guess I'm more or less curious why we're still using this outdated
> umask value with UPG. What would it take for Debian to update our
> default umask to match the UPG scheme? Is this doable for Sqeeze? Are
> there reasons for not making the switch?
Hopefully not!
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+hZg5+OKpjRpO3lAQrqxQf/Y0tHKXEiHnQePMxs/DItSecDn/aw+gsN
qcTsKw4qU6Wk95KsV5LLsRTT7uFN9/RtOtz+KUa0YaWIyLVKGMxjRbQYFceaG490
gY5QlK1AVrqHDdFipLUK12mgb63s9VDMxFqXFHpUPa5GFbMQ6RGcrN3KbxIVNeG7
khcHhOqOiATC7E0GN4jg+eSGqmD/szSlLqKBaJJVfbPbG2T91NvZqxG+cXLwuhpW
cYQqpxVA9jYLFhEBq4Fe5JhEFOUfcV+zxT8BJ0TVVsvuzvN7M5PJV7Pb9XaBXeCz
HsHU+7+Yojt2r03KeFwacjg65xZvVqQPEFNWBnnJCcd9qMdsI3iIuw==
=qeHa
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100510190...@ikki.ethgen.de
Aaron Toponce
> I still makes sense. The user will not win with the lazier umask but he
> will probably loose security.
>
> See the case the user wants another person in his own group to share
> files. Then he might set the files readable for his group only but not
> for world. So the other user can read this data. But he cannot write it
> as it might be intended.
>
> Setting the umask to 002 let the other user _edit_ all files the user
> did create in the past with that umask factual giving away most of his
> files.
The point of UPG is to not put users you don't trust in your private
group. That's why it's called "private". :) 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.
> The better Idea would be to set the user mask to 027 which then add a
> new value of security.
>
> If a user want the group to have write permissions this should be set
> explicit. By the way, with zsh you can make directory profiles which
> set the umask depending on the directory.
I'm all for increasing security, but it always comes at a cost. Nothing
in security is free. In this case, the convenience of setting up group
collaboration directories becomes a pain to administer, as the group
write bit is never set, and cron jobs, profile-specific umask values, or
FACLs are used instead, adding to the complexity of the system.
Klaus Ethgen
Hash: SHA512
Hi,
Am Mo den 10. Mai 2010 um 20:35 schrieb Aaron Toponce:
> > See the case the user wants another person in his own group to share
> > files. Then he might set the files readable for his group only but not
> > for world. So the other user can read this data. But he cannot write it
> > as it might be intended.
> >
> > Setting the umask to 002 let the other user _edit_ all files the user
> > did create in the past with that umask factual giving away most of his
> > files.
>
> The point of UPG is to not put users you don't trust in your private
> group. That's why it's called "private". :)
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!
> 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!
> I'm all for increasing security, but it always comes at a cost.
Thats true. But setting the umask to 002 will lower them for no benefit.
> In this case, the convenience of setting up group collaboration
> directories becomes a pain to administer, as the group write bit is
> never set, and cron jobs, profile-specific umask values, or FACLs are
> used instead, adding to the complexity of the system.
Well, all cases I know about where collaboration was setted up, the
person who did was knowing exactly what he did. And that is the way it
should. Don't let users do something if they do not know what
consequences it will have -- specialize in security!
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.
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+iMqZ+OKpjRpO3lAQqG3gf+M2O3qx+FFXgOT9V7VH+nx2Hcs5u1w2k9
Bk7ALBwQhZJKJV7oioyDx7GCBXnp/R2cpyyIsq8/dtT8I2+sCIuR5K6r18DRgGkB
At8Z6u0HEl/8Pl/lwnBaBhgr18iD8oUN8WXvIiS/La4n562gQfqG2Bw008QycEoz
ywWQzlOGahdfA9RA+luY3t+w6fT0+R4kU3za/C5tF6TY1pNtyyywvMrsf6sQGjES
JevSyP3FRix7scvSxtg4F/+9RBX8ei8bKe4gg13f8Em1i3p7CXbko+GfFDq0s3bs
5IxMUxN1LIXjZMaLyYwfeGasFjJlyZAb0JDY47xy9oLzQJBw8/k9xQ==
=8V8t
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100510224...@ikki.ethgen.de
Don Armstrong
> If the default umask is '0002' on a UPG system,
> then this checklist item doesn't need to be worried about.
If you want to use usergroups by default, add something like:
session optional pam_umask.so usergroups
to /etc/pam.d/login
Don Armstrong
--
I'm wrong to criticize the valor of your brave men. It's important to
die for one's country when it means being the subject of a king who
wears a ruffled collar or a pleated one.
-- Cyrano de Bergerac
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051100...@teltox.donarmstrong.com
Steve Langasek
> On Mon, 10 May 2010, Aaron Toponce wrote:
> > If the default umask is '0002' on a UPG system,
> > then this checklist item doesn't need to be worried about.
> If you want to use usergroups by default, add something like:
> session optional pam_umask.so usergroups
> to /etc/pam.d/login
Which won't have any effect on any services except for console tty logins
(no effect on X logins, ssh, etc).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Don Armstrong
> On Mon, May 10, 2010 at 05:34:32PM -0700, Don Armstrong wrote:
> > On Mon, 10 May 2010, Aaron Toponce wrote:
> > > If the default umask is '0002' on a UPG system,
> > > then this checklist item doesn't need to be worried about.
>
> > If you want to use usergroups by default, add something like:
>
> > session optional pam_umask.so usergroups
>
> > to /etc/pam.d/login
>
> Which won't have any effect on any services except for console tty logins
> (no effect on X logins, ssh, etc).
If you want those services affected, you can edit their service files
directly. (Or, if you want everything that includes common-session
affected, you can shove it in there.)
Don Armstrong
--
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
-- Patrick McGoohan as Number 6 in "The Prisoner"
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051115...@teltox.donarmstrong.com
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.
>> 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?
> 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. 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, so for the sake
of security, you might as well change it to '0007'. My argument is about
the group permission, not other.
> 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'.
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.
It's easy to say "in the name of security", without really thinking
about what you're advocating. Updating the umask value to allow the
write bit on groups when UPG is setup (as it is by default) just makes
sense. Keeping the write bit off the group, means we're too lazy to
change old historical baggage.
Klaus Ethgen
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051116...@ikki.ethgen.de
Charles Plessy
> On 5/10/2010 10:23 AM, Julien Cristau wrote:
> > On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote:
> > Are there reasons for making the switch? With user groups, umask 002 or
> > 022 doesn't make a difference. To switch off user groups, you set
> > USERGROUPS=no in adduser.conf, and that's it.
>
> The biggest reason for making the change is when group collaboration
> becomes a necessity. Suppose you have an 'devel' group on the system,
> and a central directory where the collaboration happens. Because of the
> default umask value being '0022', the users must make sure that they
> have 'umask 0002' in their shell rc file, or as appropriate, or they
> must be constantly calling chmod to change the group permissions when
> new files are created. If the default umask is '0002' on a UPG system,
> then this checklist item doesn't need to be worried about.
Dear all,
I agree with the above. See for instance the case of Alioth, where many
documented operations start with ‘umask 002’:
http://www.google.com/search?q=alioth+"umask+002"
If this umask is the convention in most other unix systems that use private
user groups by default, perhaps we should follow the priciple of least
surprise and adopt the same default. On the other hand, the priciple
of least surprise has also been invoked against having an umask of 002,
in http://bugs.debian.org/248140.
The default of 022 is also not completely in line with the Securing Debian Manual:
‘Debian's scheme solves this problem by assigning each user to their own group;
so that with a proper umask (0002) and the SETGID bit set on a given project
directory, the correct group is automatically assigned to files created in that
directory. This makes it easier for people who work on multiple projects,
because they will not have to change groups or umasks when working on shared
files.’
http://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html#s12.1.13
The decision of using 022 as a default umask seems to have been taken in 1994,
after discussions that I did not have time to read this morning:
http://lists.debian.org/debian-user/1994/03/msg00105.html
(and other off-thread messages in http://lists.debian.org/debian-user/1994/03/threads.html)
Perhaps 16 years later, in light of the experience accumulated in Debian and in the
other distributions, we can re-think the default in Debian, that seems to be
at odds with current practices?
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051200...@kunpuu.plessy.org
Russ Allbery
Aaron already explained this, but I was confused for quite some time about
the point of UPG and I'm not sure I would have gotten it from his
explanation, so let me say basically the same thing he said in different
words.
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. Then, the
right thing will happen when that user edits files in a shared space owned
by some *other* group. Without UPG, you can't safely set a umask of 002,
but when UPG is in place, you should be able to without broadening the
access granted to the user's own files by default. It then makes project
directories with a sticky GID bit *much* more useful.
UPG without a umask of 002 is pointless. One may as well just put all
users in a users group.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87fx1yk...@windlord.stanford.edu
Aaron Toponce
> Aaron already explained this, but I was confused for quite some time about
> the point of UPG and I'm not sure I would have gotten it from his
> explanation, so let me say basically the same thing he said in different
> words.
>
> 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. Then, the
> right thing will happen when that user edits files in a shared space owned
> by some *other* group. Without UPG, you can't safely set a umask of 002,
> but when UPG is in place, you should be able to without broadening the
> access granted to the user's own files by default. It then makes project
> directories with a sticky GID bit *much* more useful.
>
> UPG without a umask of 002 is pointless. One may as well just put all
> users in a users group.
Well said.
Noah Meyerhans
> UPG without a umask of 002 is pointless. One may as well just put all
> users in a users group.
Right, our default setup is a strange and basically meaningless blend of
two different approaches to user primary groups.
One approach would be for users to be in a shared group (typically
"users", but a project- or organization-specific group would also be
common) and would have a more restrictive default umask (probably 022,
or maybe something even more strictive like 077). Users can than share
files with other members of their primary group by granting access using
chmod.
The other approach is to use private groups, like we do in Debian, but
with a more permissive default umask (probably 002). Collaboration is
then achieved by setting the setgid bit on a directory where the
collaborative work is being done.
Either of these approaches is OK. User's files are not writable by
anybody but that user unless explicit steps are taken.
Our default settings, however, break both of these approaches. The
first doesn't work because the group permissions are effectively
meaningless, since there isn't anybody but the user in the group. The
second is broken because the umask is too restrictive, so changing the
group ownership of a file doesn't accomplish anything.
It would be interesting to see the discussion that lead to our current
default setup, if anybody feels like combing the archives...
noah
Holger Levsen
On Mittwoch, 12. Mai 2010, Noah Meyerhans wrote:
> Right, our default setup is a strange and basically meaningless blend of
> two different approaches to user primary groups.
[...]
> Either of these approaches is OK. User's files are not writable by
> anybody but that user unless explicit steps are taken.
>
> Our default settings, however, break both of these approaches.
[..]
> It would be interesting to see the discussion that lead to our current
> default setup, if anybody feels like combing the archives...
Wouldn't it be more interesting to file a bug and get it fixed for squeeze?
Mailing list discussions tend to get, well, forgotten... :)
cheers,
Holger
Stefano Zacchiroli
> the point of UPG and I'm not sure I would have gotten it from his
> explanation, so let me say basically the same thing he said in different
> words.
> UPG without a umask of 002 is pointless. One may as well just put all
> users in a users group.
[ As always, I'm impressed by your ability to expose things clearly ]
Can you, or Aaron, or anyone else interested in the matter submit a
proper bug report (at least against "login" for /etc/login.defs)
summarizing the point in favor and against the change (if any resisted
this presentation)?
That way it would be easier to track the status of this proposed change.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Charles Plessy
thanks
Dear Santiago,
You probably have seen the discussion about user private groups on debian-devel
this week: http://lists.debian.org/msgid-search/4BE830C8...@gmail.com
The core argument is that since user private groups are not meant to be shared,
and that therefore an umask of 002 is not creating security risk. On the other
hand, an umask of 022 is preventing from harvesting the benefits of user
private groups. See in particular the summarry from Russ Allbery:
http://lists.debian.org/87fx1yk...@windlord.stanford.edu
I read this bug report (http://bugs.debian.org/248140) and indeed, if users
have been used that Debian has an umask of 022, perhaps the change could be
surprising. However, it would not affect existing systems. I can propose a
patch to the release notes if pepole think it would be useful.
If no stronger objections against a change from 022 to 002 is raised, would you
agree changing base-files so that /etc/profile uses 002 on new systems?
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Andrei Popescu
> On 2010-05-13, Charles Plessy <ple...@debian.org> wrote:
> > If no stronger objections against a change from 022 to 002 is raised, would you
> > agree changing base-files so that /etc/profile uses 002 on new systems?
>
> to sync unix users and groups on such systems, if they aren't set up to
> use UPG too? So that would need a big fat warning in the release notes
> and somehow I fear bad PR. :P
How about a message on debian-security-announce ?
Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Philipp Kern
> agree changing base-files so that /etc/profile uses 002 on new systems?
Doesn't that lead to "great fun" if you activate NIS or similar means
to sync unix users and groups on such systems, if they aren't set up to
use UPG too? So that would need a big fat warning in the release notes
and somehow I fear bad PR. :P
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnhunhsn...@kelgar.0x539.de
Lucas Nussbaum
> On 2010-05-13, Charles Plessy <ple...@debian.org> wrote:
> > If no stronger objections against a change from 022 to 002 is raised, would you
> > agree changing base-files so that /etc/profile uses 002 on new systems?
>
> Doesn't that lead to "great fun" if you activate NIS or similar means
> to sync unix users and groups on such systems, if they aren't set up to
> use UPG too?
How would that result in a problem?
- Lucas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100513094...@xanadu.blop.info
Santiago Vila
> found 248140 5.3
> thanks
>
> Dear Santiago,
>
> You probably have seen the discussion about user private groups on
> debian-devel this week:
> http://lists.debian.org/msgid-search/4BE830C8...@gmail.com The
> core argument is that since user private groups are not meant to be
> shared, and that therefore an umask of 002 is not creating security
> risk. On the other hand, an umask of 022 is preventing from
> harvesting the benefits of user private groups. See in particular
> the summarry from Russ Allbery:
> http://lists.debian.org/87fx1yk...@windlord.stanford.edu
>
> I read this bug report (http://bugs.debian.org/248140) and indeed,
> if users have been used that Debian has an umask of 022, perhaps the
> change could be surprising. However, it would not affect existing
> systems. I can propose a patch to the release notes if pepole think
> it would be useful.
Yes, I think this change is important enough to be documented in
release notes. You might want to mention the possible gotchas, like,
for example, performing "scp -p" from a system with umask 002 to a
system without UPG when there are already files with mode 664 floating
around.
> If no stronger objections against a change from 022 to 002 is
> raised, would you agree changing base-files so that /etc/profile
> uses 002 on new systems?
No objection.
In fact, the status of /etc/profile as a "configuration file which is
not a conffile but instead it's created only on new installs" allows us
to change the default to whatever thing we consider more sensible
without worrying too much about the principle of least surprise, as the
change is only in effect on new installs.
Will be done in base-files 5.4.
Thanks.
Philipp Kern
> On 13/05/10 at 09:34 +0000, Philipp Kern wrote:
>> On 2010-05-13, Charles Plessy <ple...@debian.org> wrote:
>> > If no stronger objections against a change from 022 to 002 is raised, would you
>> > agree changing base-files so that /etc/profile uses 002 on new systems?
>> Doesn't that lead to "great fun" if you activate NIS or similar means
>> to sync unix users and groups on such systems, if they aren't set up to
>> use UPG too?
> How would that result in a problem?
User files writeable by others by default because, as I said if they aren't
set up to use UPG, they might share a "users" group?
(Not so much a problem if you default home directories to 0700 though.)
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnhunm4q...@kelgar.0x539.de
Aaron Toponce
> On 2010-05-13, Charles Plessy <ple...@debian.org> wrote:
>> If no stronger objections against a change from 022 to 002 is raised, would you
>> agree changing base-files so that /etc/profile uses 002 on new systems?
>
> Doesn't that lead to "great fun" if you activate NIS or similar means
> to sync unix users and groups on such systems, if they aren't set up to
> use UPG too? So that would need a big fat warning in the release notes
> and somehow I fear bad PR. :P
Can you provide a documented use case for NIS or NIS+? Speculation is
one thing, implementing it is another.
I'm utilizing OpenLDAP with autofs to mount user home directories on
RHEL 5 systems when users login. Everything plays nice, just as you
would expect, permission-wise. They have their own UPG, and the default
umask is still 0002. Because most of these are developers developing in
/u01, it's trivial to setup the collaboration as previously mentioned.
I don't have experience with NIS or NIS+, however, so I would be
interested in learning any problems with either of these setups.
Russ Allbery
> On 2010-05-13, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote:
>> On 13/05/10 at 09:34 +0000, Philipp Kern wrote:
>>> Doesn't that lead to "great fun" if you activate NIS or similar means
>>> to sync unix users and groups on such systems, if they aren't set up
>>> to use UPG too?
>> How would that result in a problem?
> User files writeable by others by default because, as I said if they
> aren't set up to use UPG, they might share a "users" group?
I'm sure that I've gotten prompted by debconf somewhere, by something,
about whether I want to use UPG, although I can't remember what package
that is. But if we're already asking the question, we should be able to
make the umask value conditional on that same question. Then it's just a
matter of ensuring that the question is clear enough about when you would
not want to enable this.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/877hn7s...@windlord.stanford.edu
Russ Allbery
> On 5/13/2010 3:34 AM, Philipp Kern wrote:
>> Doesn't that lead to "great fun" if you activate NIS or similar means
>> to sync unix users and groups on such systems, if they aren't set up to
>> use UPG too? So that would need a big fat warning in the release notes
>> and somehow I fear bad PR. :P
> Can you provide a documented use case for NIS or NIS+? Speculation is
> one thing, implementing it is another.
Well, whenever you want to share the same set of users across a bunch of
systems, you use something like NIS. You're actually doing so yourself:
> I'm utilizing OpenLDAP with autofs to mount user home directories on
> RHEL 5 systems when users login.
This is equivalent. The key part is this:
> Everything plays nice, just as you would expect, permission-wise. They
> have their own UPG, and the default umask is still 0002.
You're creating UPGs in your LDAP environment. As long as you do that,
that's fine. Philipp's point, I believe, is that, first, institutional
LDAP environments probably aren't going to have UPG set up (Stanford's
doesn't, for example; we have a users group shared by all users), and
second, there's no way for the Debian package to tell whether the LDAP or
NIS environment is going to have UPG.
The root of the problem is that the decision to use UPG is done in one
place and the umask is set in a different place, and there's one
combination out of the four possible ones that's insecure by default.
I don't think this is insurmountable, but it definitely needs to be
documented.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/8739xvs...@windlord.stanford.edu
Aaron Toponce
> Will be done in base-files 5.4.
I just saw the change committed. Thank you very much! This is good news.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25
Klaus Ethgen
Hash: SHA512
Am Do den 13. Mai 2010 um 18:45 schrieb Aaron Toponce:
> On 5/13/2010 3:48 AM, Santiago Vila wrote:
> > Will be done in base-files 5.4.
>
> I just saw the change committed. Thank you very much! This is good news.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25
A black day in the security of Debian. Well.. One more.
- -- 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+yD75+OKpjRpO3lAQrSbQf+Or9BgLCU6MIQoQgGMpm3P23STT4PnPcR
EodAccFEGFB+QntVIDczz6Tt2VFIlErkLoJ1YRrAYbEB8fdbvx12ptZA8jY0RzB1
e52qfwMmUOoGrzut0p9teocE8zQ7rHev2KPvhqFmnYFJtm7CCH47uY5w+w5XfNs0
BxwnjH7vBlxle1SOHRteWf8E7L81+CID+MhGUCozWHEWrMNhQyQU6cCMrP58MiUM
fHscSpN+5rQsr+6t6B6cLvgiZCApqGeuHKxpndA2gCUY6Oid+WW2i7UoMUfheJ3M
WMbS+rc0fi2xwosC29cO2vem7vv7tR5Ha9WH4ji4zNS1/6rxis10ew==
=WSAu
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100513225...@ikki.ethgen.de
Petter Reinholdtsen
[Santiago Vila]
> Will be done in base-files 5.4.
Great. This has been the default in Debian Edu for several years, and
changing the default to work properly with UPG will remove the need
for Debian Edu to edit the default umask. Btw, why is the umask set
at all in base-files? It would be better to use PAM to set it.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Danjean
> On 5/13/2010 3:48 AM, Santiago Vila wrote:
>> Will be done in base-files 5.4.
>
> I just saw the change committed. Thank you very much! This is good news.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25
I'm happy with this move. However, there is still an interaction with ssh
to deal with:
vdanjean@eyak:~$ chmod -Rv g+w .ssh/authorized_keys
vdanjean@eyak:~$ ssh localhost
vdanjean@localhost's password:
And, in /var/log/auth.log:
May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
vdanjean@eyak:~$ chmod -Rv g-w .ssh/authorized_keys
le mode de « .ssh/authorized_keys » a été modifié en 0644 (rw-r--r--).
vdanjean@eyak:~$ ssh localhost
You have mail.
Last login: Tue May 11 17:10:30 2010
vdanjean@eyak:~$
My system is in UPG but I was using default umask 022
Regards
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joey Hess
> I'm happy with this move. However, there is still an interaction with ssh
> to deal with:
> vdanjean@eyak:~$ chmod -Rv g+w .ssh/authorized_keys
> vdanjean@eyak:~$ ssh localhost
> vdanjean@localhost's password:
> And, in /var/log/auth.log:
> May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
maildrop has the same problem with .mailfilter files.
--
see shy jo
Andreas Hemel
As does exim with .forward files. Should this be reported as a bug
against exim, now that the default umask will change?
Andreas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100514225...@ko-bal.daishan.de
Santiago Vila
Problems like that are expected to happen, and I think we should be
ready to fix them as they are found, so that the umask setting can
really be a choice of the system admin, not an imposition of certain
key programs who do not work well enough on systems having UPG and a
default umask of 002.
I remember that procmail had a similar problem, and the author
implemented a build macro for systems having UPG. From the changelog:
1999/03/02: v3.12
Changes to procmail:
- Don't use $HOME/.procmailrc if it's group-writable or in a
group-writable directory, unless it's the user's default group
and GROUP_PER_USER is set in config.h
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Santiago Vila
> On Fri, May 14, 2010 at 01:21:41PM -0400, Joey Hess wrote:
> > Vincent Danjean wrote:
> > > I'm happy with this move. However, there is still an interaction with ssh
> > > to deal with:
> >
> > > vdanjean@eyak:~$ chmod -Rv g+w .ssh/authorized_keys
> > > vdanjean@eyak:~$ ssh localhost
> > > vdanjean@localhost's password:
> > > And, in /var/log/auth.log:
> > > May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
> >
> > maildrop has the same problem with .mailfilter files.
>
> As does exim with .forward files. Should this be reported as a bug
> against exim, now that the default umask will change?
I think so.
Ideally, we should support both 022 and 002 as umask.
Unfortunately, we have been using 022 for so long that we don't even
know what things have to be changed so that "everything works" when
umask is 002.
So, for practical purposes, setting 002 as the default umask is
probably the best (or maybe just the only) way to discover what needs
to be fixed when the umask is 002.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Klaus Ethgen
Hash: SHA512
Am Sa den 15. Mai 2010 um 0:24 schrieb Santiago Vila:
> I remember that procmail had a similar problem, and the author
> implemented a build macro for systems having UPG. From the changelog:
>
> 1999/03/02: v3.12
> Changes to procmail:
> - Don't use $HOME/.procmailrc if it's group-writable or in a
> group-writable directory, unless it's the user's default group
> and GROUP_PER_USER is set in config.h
Urgh, and as in debian this is set, procmail is per default unsave on
all systems where non UPG is used or where the user like to use his own
UPG for sharing purpose!?
To change all that software just to let the umask be convenient for just
one very special use case and make all the rest all that unsave? Sorry,
but this is like the openssl disaster just intentional.
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+3kap+OKpjRpO3lAQpLGwgAry8FHXhr2T7uNP5AY7bTOmtS5zQ4wjif
CdLQXVviqpksSEk27yqBnt3qzsSGayKphZqEN2jskCcYCtUpEY+zSCigUy/z5fVb
IDLd80y5dVdGf9eiytidCUjaJ+fpB2sOQwFJ91H9cBPUEQHyPgAkuzXsyf2ORrgV
0+1vA4HlmfF0hsEHLfucYUF3xIwU4UczAoMiEDTA3avUYcoUCf3ELVrJLXuCwk6V
PXNw0Fzi95gwCB9Su8tBwNuccy4YCT5OC2Cxt5KlyBoLLvjXEXPs+GKK2W2YPmoH
t0DNg1phu1iS9WqeiqG33B0uGHFjpShlIajnB665llX/1KPdf2K95w==
=U8oX
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051500...@ikki.ethgen.de
Joey Hess
> Urgh, and as in debian this is set, procmail is per default unsave on
> all systems where non UPG is used or where the user like to use his own
> UPG for sharing purpose!?
>
> To change all that software just to let the umask be convenient for just
> one very special use case and make all the rest all that unsave? Sorry,
> but this is like the openssl disaster just intentional.
If you give untrusted users write access to your home directory or to
individual dotfiles, you will discover:
* A handful of programs (ssh, exim, maildrop) will try to detect this
and block it.
* The majority of programs, from bash on down, will happily use their
dotfiles no matter who owns them.
I'm curious about why those few programs do implement their additional
checks. There's probably some interesting history there.
But requiring every program that has a dotfile to implement security
checking for that dotfile is doomed to failure, and so, sensibly, that
is not done. Your typical program with a dotfile relies on the user
choosing a safe combination of umask and directory permissions for its
security.
--
see shy jo, not responding to this person's continued openssh trolling
Christoph Anton Mitterer
> Your typical program with a dotfile relies on the user
> choosing a safe combination of umask and directory permissions for its
> security.
At least half (!) of the bill (the default umask) is now taken away from
the user, as he does not manually choose and decide to either set it
generally to 022 or give a specific dotfile some g+rw rights...
Cheers,
Chris.
Joey Hess
> I'm happy with this move. However, there is still an interaction with ssh
> to deal with:
> vdanjean@eyak:~$ chmod -Rv g+w .ssh/authorized_keys
> vdanjean@eyak:~$ ssh localhost
> vdanjean@localhost's password:
> And, in /var/log/auth.log:
> May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
>
> vdanjean@eyak:~$ chmod -Rv g-w .ssh/authorized_keys
> le mode de « .ssh/authorized_keys » a été modifié en 0644 (rw-r--r--).
> vdanjean@eyak:~$ ssh localhost
> You have mail.
> Last login: Tue May 11 17:10:30 2010
> vdanjean@eyak:~$
>
> My system is in UPG but I was using default umask 022
FWIW, for openssh this is supposed to be fixed in version 1:4.1p1-3.
See #314347. It was changed to allow group-writable files if
the owner is the only member in the group.
--
see shy jo
Vincent Danjean
Somethink is wrong here. Should 314347 be reopened ?
vdanjean@eyak:~$ LC_ALL=C apt-cache policy openssh-server
openssh-server:
Installed: 1:5.5p1-3
Candidate: 1:5.5p1-3
Version table:
*** 1:5.5p1-3 0
500 http://ftp.fr.debian.org unstable/main Packages
500 http://ftp.fr.debian.org testing/main Packages
100 /var/lib/dpkg/status
1:5.1p1-5 0
500 http://ftp.fr.debian.org stable/main Packages
1:4.3p2-9etch3 0
500 http://ftp.fr.debian.org oldstable/main Packages
vdanjean@eyak:~$ cat /etc/group /etc/passwd | grep '^vdanjean'
vdanjean:x:1000:
vdanjean:x:1000:1000:Vincent Danjean,,,:/home/vdanjean:/bin/bash
vdanjean@eyak:~$
--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Metzler
[...]
> Problems like that are expected to happen, and I think we should be
> ready to fix them as they are found, so that the umask setting can
> really be a choice of the system admin, not an imposition of certain
> key programs who do not work well enough on systems having UPG and a
> default umask of 002.
> I remember that procmail had a similar problem, and the author
> implemented a build macro for systems having UPG. From the changelog:
> 1999/03/02: v3.12
> Changes to procmail:
> - Don't use $HOME/.procmailrc if it's group-writable or in a
> group-writable directory, unless it's the user's default group
> and GROUP_PER_USER is set in config.h
Hello,
afaiui we have this problem:
#1 Debian supports both UPG and non-UPG setups.
#2 UPG with umask 022 is useless.
#3 non-UPG with umask 002 is insecure.
#4 We cannot reliably detect UPG-setups. (The setting
USERGROUPS=yes/no in /etc/adduser.conf is not relevant, e.g. in a
NIS szenario users are generated on the master system.)
The solution applied to procmail, disabling .procmailrc permission
sanity check at compile time is not really a bugfix, but a policy
change, dropping #1 in favour of #2.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1512c7-...@argenau.downhill.at.eu.org
Christoph Anton Mitterer
> #2 UPG with umask 022 is useless.
It makes that every user has its own group, and that other users can be
added to it.
This alone doesn't have any effect of course, as such added users have
read rights anyway.
But now it's easy for the owner of files to selectively set
write-permissions for single files.
Cheers,
Chris.
Christoph Anton Mitterer
> Why is an own group needed for this? Can't the admin just create groups
> as needed where both users shall belong?
of UPGs completely...
Cheers,
Chris.
Charles Plessy
>
> Yes, I think this change is important enough to be documented in
> release notes. You might want to mention the possible gotchas, like,
> for example, performing "scp -p" from a system with umask 002 to a
> system without UPG when there are already files with mode 664 floating
> around.
Dear Santiago and everybody,
I was glad to see that a patch has already been proposed to the release notes.
To keep track with the other changes that will help to smooth the transition,
I have created a wiki page:
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100515152...@kunpuu.plessy.org
Willi Mann
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. Then, the
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.
WM
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/hsn1gf$cst$1...@dough.gmane.org
Thomas Hochstein
>> #2 UPG with umask 022 is useless.
> Why is it?
See <http://lists.debian.org/debian-devel/2010/05/msg00315.html>.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/ldd.10051...@thorondor.akallabeth.de
Don Armstrong
> #4 We cannot reliably detect UPG-setups. (The setting
> USERGROUPS=yes/no in /etc/adduser.conf is not relevant, e.g. in a
> NIS szenario users are generated on the master system.)
You don't need to detect UPG setups with 100% reliability; you can
just do the following:
1. If there a possibility of this being a UPG setup:
2. If this user's group has the same name and GID as the user's name and UID:
3. default umask of 0002
4. otherwise, default umask of 0022
In cases where you make a mistake and this isn't a UPG setup, step #2
should stop you if this is actually going to be a problem (and not
coincidentally, this is the check that pam_umask already does when you
give it the usergroups option.)
You can figure out #1 by whether or not adduser.conf is set to use
USERGROUPS, and if it is, the default for pam should probably[1]
default to adding "session optional pam_umask.so usergroups" to
common-session.
Alternatively, #2 can be done in /etc/profile using id, which should
work just fine, even on NIS setups.
Don Armstrong
1: Steve will hopefully correct me if I'm mistaken here.
--
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
-- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051521...@teltox.donarmstrong.com
Russ Allbery
> 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.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87eihcc...@windlord.stanford.edu
Roger Leigh
> Willi Mann <fos...@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.
The standard getgrnam/getgrgid (or the _r variants) are competely
portable and give you the list of users who are group members (so a simple
check through the user list is quick and easy). From the shell
"getent group $group" should return an empty user list.
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Russ Allbery
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
>> 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.
> The standard getgrnam/getgrgid (or the _r variants) are competely
> portable and give you the list of users who are group members (so a
> simple check through the user list is quick and easy). From the shell
> "getent group $group" should return an empty user list.
I was thinking more in terms of access restrictions than APIs. Being able
to ask who is a member of a particular group is a potential privacy
violation, so I wasn't sure if there were group systems in widespread use
that would refuse to tell you any information about anyone other than
yourself unless you had root or similar elevated credentials.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87bpcgp...@windlord.stanford.edu
Drake Wilson
> You don't need to detect UPG setups with 100% reliability; you can
> just do the following:
>
> 1. If there a possibility of this being a UPG setup:
> 2. If this user's group has the same name and GID as the user's name and UID:
Hrmbl. I have existing Debian systems that use UPG with UIDs and GIDs
decidedly non-matching. It only takes one extra addgroup without a
corresponding adduser in the default configuration to make the IDs go
out of sync, I think---or at least that's what I've observed with both
lenny and current sid. I kind of doubt testing numeric ID equivalence
between those two namespaces is a good idea.
---> Drake Wilson
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100515231...@drache.begriffli.ch
Andreas Metzler
> Quoth Don Armstrong <d...@debian.org>, on 2010-05-15 14:40:05 -0700:
>> You don't need to detect UPG setups with 100% reliability; you can
>> just do the following:
>> 1. If there a possibility of this being a UPG setup:
>> 2. If this user's group has the same name and GID as the user's name and UID:
> Hrmbl. I have existing Debian systems that use UPG with UIDs and GIDs
> decidedly non-matching. It only takes one extra addgroup without a
> corresponding adduser in the default configuration to make the IDs go
> out of sync,
[...]
That matches my personal experience.
argenau:~# addgroup blah
Adding group `blah' (GID 1005) ...
Done.
argenau:~# adduser nongidmatch
Adding user `nongidmatch' ...
Adding new group `nongidmatch' (1006) ...
Adding new user `nongidmatch' (1005) with group `nongidmatch' ...
[...]
Part 2 the heuristic could be changed to "names of group and user
are identical and user is the only member of the group".
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/p2h4c7-...@argenau.downhill.at.eu.org
Vincent Bernat
vers 23:34, Russ Allbery <r...@debian.org> disait :
>> 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.
If you are thinking about checking if the user is alone in her group,
this seems a bad idea. I may be alone in "users" group. But I may later
add someone else. My umask will then change but all already created
files will be readable and writable by the new user.
Comparing names seems a better solution.
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Harald Braumann
> > 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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aaron Toponce
> 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.
I proposed this change to the /etc/profile file [1]. This logic seems
"good enough" to determine UPG accounts.
Further discussion however shows that other than root, system users
don't have login shells, and as such, won't process the /etc/profile
file. Also, because root has its own UPG, there's really no need for the
logic. My only question is then, why is their default shell /bin/sh, and
not /bin/false or /usr/sbin/nologin if they indeed are not login shells?
The "staff" and "users" groups might be problematic, if system
administrators are using those groups similar to how Solaris or HPUX are
using them (respectfully). However, I would venture that if the
administrator has his system setup that way, he's aware of the necessary
umask needed for that setup. If there are systems setup in this manner,
we'll likely see bug reports about it.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#70
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
Aaron Toponce
> Somethink is wrong here. Should 314347 be reopened ?
Agreed. It's not working as it should. Running openssh-client version
1:5.5p1-3, and setting the write bit on my private group seems to keep
the client from behaving as expected.
The Fungi
> 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.
This is racy, unfortunately (at least by itself). Consider a non-UPG
system which starts with one user... this check passes and files get
created with group write flagged. Later, subsequent users appear
sharing that same group and the default umask stops making new files
group-writeable, but the first user's original files are now able to
be modified by others (and then his account is immediately at risk
of being taken over by one of the new users without his knowledge).
Of course, coupled with other checks like uname==gname, parsing
login.defs, et cetera, it could add an extra layer of assurance.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
> Further discussion however shows that other than root, system users
> don't have login shells, and as such, won't process the /etc/profile
> file. Also, because root has its own UPG, there's really no need for the
> logic. My only question is then, why is their default shell /bin/sh, and
> not /bin/false or /usr/sbin/nologin if they indeed are not login shells?
Because the further discussion was wrong. System users have login shells
in Debian. (I consider this a very long-standing bug.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87pr0vg...@windlord.stanford.edu
Russ Allbery
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
>> 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.
> This is racy, unfortunately (at least by itself). Consider a non-UPG
> system which starts with one user... this check passes and files get
> created with group write flagged. Later, subsequent users appear sharing
> that same group and the default umask stops making new files
> group-writeable, but the first user's original files are now able to be
> modified by others (and then his account is immediately at risk of being
> taken over by one of the new users without his knowledge).
> Of course, coupled with other checks like uname==gname, parsing
> login.defs, et cetera, it could add an extra layer of assurance.
Right, exactly. You also check that username == group name, but it's an
additional check to be sure that the group doesn't just happen to look
like a user private group but isn't.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ljbjg...@windlord.stanford.edu
Harald Braumann
> On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote:
> > 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.
>
> This is racy, unfortunately (at least by itself). Consider a non-UPG
> system which starts with one user... this check passes and files get
> created with group write flagged. Later, subsequent users appear
> sharing that same group and the default umask stops making new files
> group-writeable, but the first user's original files are now able to
> be modified by others (and then his account is immediately at risk
> of being taken over by one of the new users without his knowledge).
>
> Of course, coupled with other checks like uname==gname, parsing
> login.defs, et cetera, it could add an extra layer of assurance.
I'd call it an extra layer of assumptions. I already get the shivers
just thinking about the kind of complexity that is invented here. Now
it's sufficient to have a look in /etc/profile to *know* the umask
that will be set. If that scheme were implemented, I'd have to read code,
several files and query ldap, or whatever is used, to *assume* what
umask might be set.
Please don't do that. If non-UPG systems should be supported, keep the
umask at 022 and let the admin edit a single line to change it, if
this is needed and he knows it's a pure UPG system.
Cheers,
harry
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Felipe Sateler
> If non-UPG systems should be supported, keep the
> umask at 022 and let the admin edit a single line to change it, if
> this is needed and he knows it's a pure UPG system.
Is there a reason to support non-UPG systems?
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/hspqv6$qie$1...@dough.gmane.org
Aaron Toponce
> Because the further discussion was wrong. System users have login shells
> in Debian. (I consider this a very long-standing bug.)
Then the logic should be in play. System users don't necessarily have a
private group, so their umask should be 0022. If they are not intended
to be login accounts, then their default shell should be changed to
/usr/sbin/nologin or /bin/false.
Santiago Vila
> Aaron Toponce <aaron....@gmail.com> writes:
>
> > Further discussion however shows that other than root, system users
> > don't have login shells, and as such, won't process the /etc/profile
> > file. Also, because root has its own UPG, there's really no need for the
> > logic. My only question is then, why is their default shell /bin/sh, and
> > not /bin/false or /usr/sbin/nologin if they indeed are not login shells?
>
> Because the further discussion was wrong. System users have login shells
> in Debian. (I consider this a very long-standing bug.)
They have login shells in the sense that their shell field in /etc/passwd
is /bin/sh, but if they do not really "login" to the system, then they
do not read /etc/profile.
In either case, if we plan to set default umask in /etc/login.defs or
using PAM, I will happily drop the umask setting from /etc/profile,
as we don't need to have the required "logic" by duplicate.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1...@kolmogorov.unex.es
Russ Allbery
> On 16/05/10 16:50, Harald Braumann wrote:
>> If non-UPG systems should be supported, keep the umask at 022 and let
>> the admin edit a single line to change it, if this is needed and he
>> knows it's a pure UPG system.
> Is there a reason to support non-UPG systems?
Yes. Many Debian users already have non-UPG systems and are not going to
change their enterprise-wide account provisioning in order to accomodate
UPG. Remember, the decision to use UPG in many environments is not a
per-system decision. If the users are coming from some external source
like LDAP, it's an enterprise-wide decision and the person installing
Debian may not have any choice in the matter.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87iq6ne...@windlord.stanford.edu
Aaron Toponce
> They have login shells in the sense that their shell field in /etc/passwd
> is /bin/sh, but if they do not really "login" to the system, then they
> do not read /etc/profile.
>
> In either case, if we plan to set default umask in /etc/login.defs or
> using PAM, I will happily drop the umask setting from /etc/profile,
> as we don't need to have the required "logic" by duplicate.
Curious, if umask isn't specified explicitly, what is it? For UID 1-99,
what we're discussing here, what would happen for their umask value?
Will it be 0022? 0000? Something else?
Also, if the system users aren't processing a login shell, then why
isn't their default login shell /usr/bin/nologin or /bin/false? Should a
wishlist bug be submitted against this?
Felipe Sateler
> Felipe Sateler<fsat...@gmail.com> writes:
>> On 16/05/10 16:50, Harald Braumann wrote:
>
>>> If non-UPG systems should be supported, keep the umask at 022 and let
>>> the admin edit a single line to change it, if this is needed and he
>>> knows it's a pure UPG system.
>
>> Is there a reason to support non-UPG systems?
>
> Yes. Many Debian users already have non-UPG systems and are not going to
> change their enterprise-wide account provisioning in order to accomodate
> UPG. Remember, the decision to use UPG in many environments is not a
> per-system decision. If the users are coming from some external source
> like LDAP, it's an enterprise-wide decision and the person installing
> Debian may not have any choice in the matter.
I mean, is there a reason for why I would want a non-UPG system? From
what I've read in this thread, a common users group presents no
advantage over UPG. Debian as an OS provider may be "forced" to support
non-UPG configurations for reasons like you state, but I'm more interest
in why would an enterprise want to take such a decision.
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/hsq23k$br8$1...@dough.gmane.org
Russ Allbery
> I mean, is there a reason for why I would want a non-UPG system? From
> what I've read in this thread, a common users group presents no
> advantage over UPG. Debian as an OS provider may be "forced" to support
> non-UPG configurations for reasons like you state, but I'm more interest
> in why would an enterprise want to take such a decision.
In our case, because we've historically only ever used one GID in our
enterprise LDAP (previously NIS) user database, so it's very difficult to
safely introduce UPG since individual systems have used GIDs for various
other reasons.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87eihbe...@windlord.stanford.edu
Thomas Hochstein
> I mean, is there a reason for why I would want a non-UPG system?
What about a hosting environment where you need to have user files
world-readable (HTML documents or (PHP) scripts readable by www-data),
but don't want them readable by other customers? You could achieve
that by putting all customers in a common group ("users") and setting
the files 604 or the like.
-thh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/ldd.10051...@thorondor.akallabeth.de
Brian May
> In our case, because we've historically only ever used one GID in our
> enterprise LDAP (previously NIS) user database, so it's very difficult to
> safely introduce UPG since individual systems have used GIDs for various
> other reasons.
In our case we use the GID to reflect the department that the user
belongs to, and this group is used for file system quotas (amongst
other things).
Plus the fact that setting up an extra group for every user in LDAP is
extra complexity, extra chance for mistakes, for no gain for us.
Besides, if the requirement is to be able to create files in certain
directories with group permissions (I think that is what this is
about, but only skimming), can't you do something with default ACLs
that do the same thing on given directories without the extra
complexity to the groups?
Or have I got this wrong?
--
Brian May <br...@microcomaustralia.com.au>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTilkqnIX8KEr0_4Wt...@mail.gmail.com
Russ Allbery
> Besides, if the requirement is to be able to create files in certain
> directories with group permissions (I think that is what this is about,
> but only skimming), can't you do something with default ACLs that do the
> same thing on given directories without the extra complexity to the
> groups?
> Or have I got this wrong?
You can do similar things with POSIX ACLs. There's some disagreement over
which one is extra complexity. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87zkzzw...@windlord.stanford.edu
Timo Juhani Lindfors
> In either case, if we plan to set default umask in /etc/login.defs or
/etc/login.defs is not read when I login to openssh server and it has
"UseLogin" set to false. If I enable UseLogin then X11 forwarding
stops working [1]. To me it seems that login.defs can not be the only
place where umask is set.
[1] man sshd_config:
"Specifies whether login(1) is used for interactive login sessions.
The default is ``no''. Note that login(1) is never used for remote
command execution. Note also, that if this is enabled, X11Forwarding
will be disabled because login(1) does not know how to handle xauth(1)
cookies."
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christoph Anton Mitterer
wrote:
> Is there a reason to support non-UPG systems?
btw: While I stopped at some point commenting that issue, when I realised
that general security concerns were simply ignored,... I've seen that there
were plans to automatically detect whether a user could have "secure" UPG,
right?
May I suggest the following:
Either:
1) Debian should make this decision fully configurable (whether to use UPG
and which umask _system wide_ (!) or not). Of course it is already
configurable, but I mean something like configuration during installer
phase, or via debconf at some package where this fits to.
At that/those places, when choosing UPG, only the supposedly "secure"
default umasks could be presented and the user could be taught about the
pros and cons of UPGs.
Or:
2) It should be easy to prevent the now ongoing changes (switching default
umask and so on), and for new installations, easy to go back to the old
way.
3) If you make such automatic checks whether a user can have UPGs
"securely", I guess you should take care that these checks are
"dynamically", as a user may change his groups.
btw2: Has there been a final decision whether this UPG-stuff is also
enabled for system users? Especially things like the users from postgresql,
or other daemons?
btw3: As this change seems to be decided, wouldn't it make sense to change
the UMASK value in login.defs and the currently documentation that tells
some secure values:
# 022 is the "historical" value in Debian for UMASK when it was used
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#UMASK 022
to the "new" ones with the insecure ones:
# 022 is the "historical" value in Debian for UMASK when it was used
# 002 is the new default for use with user private groups.
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#UMASK 002
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/17db8d7d1bc34528...@imap.dd24.net
Vincent Danjean
> On 05/15/2010 12:16 AM, Vincent Danjean wrote:
>> Somethink is wrong here. Should 314347 be reopened ?
>
> Agreed. It's not working as it should. Running openssh-client version
> 1:5.5p1-3, and setting the write bit on my private group seems to keep
> the client from behaving as expected.
I just opened a new bug (d-devel is in CC) as 314347 is about openssh-client
and this problem is in openssh-server. However, the fix is probably similar.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christoph Anton Mitterer
wrote:
> how about you file bugs _with patches_? Talk is cheap.
- change umask from 022 or 002 to either 027 (or 077).
- disable UPGs altogether, as I feel that they contradict the way how
groups were intended by our POSIX/UNIX fathers (and mothers).
But I guess non of them wouldn't be received enthusiastically, would they?
;)
Best wishes,
Chris.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/b55a9e6f8550f986...@imap.dd24.net
Harald Braumann
> Will be done in base-files 5.4.
I think that this change was done prematurely. There is still the
issue of a Debian system running in a non-UPG environment. And so far
I haven't seen a resolution for this point in the discussion.
Cheers,
harry
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
See below libpam umask could be used for this task and extended if needed.
>
> btw3: As this change seems to be decided, wouldn't it make sense to change
> the UMASK value in login.defs and the currently documentation that tells
> some secure values:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 027, or even 077, could be considered better for privacy
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK 022
>
> to the "new" ones with the insecure ones:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 002 is the new default for use with user private groups.
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK 002
>
Using libpam umask will be simplier:
Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=022
Only one place and documented.
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTiliLNfhaXu7G5CHw...@mail.gmail.com
Mike Hommey
> On Mon, May 17, 2010 at 12:26 PM, Harald Braumann <ha...@unheit.net> wrote:
> > On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
> >
> >> Will be done in base-files 5.4.
> >
> > I think that this change was done prematurely. There is still the
> > issue of a Debian system running in a non-UPG environment. And so far
> > I haven't seen a resolution for this point in the discussion.
>
> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
>
> [opition] usergroups
>
> If the user is not root, and the user ID is equal to the group ID,
> and the username is the same as primary group name, the umask group
> bits are set to be the same as owner bits (examples: 022 -> 002, 077
> -> 007).
And it was said in this thread that UID == GID is not always true with
UPG. You only need to create a group for that to become false for users
you would create afterwards.
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
>
>> Will be done in base-files 5.4.
>
> I think that this change was done prematurely. There is still the
> issue of a Debian system running in a non-UPG environment. And so far
> I haven't seen a resolution for this point in the discussion.
I believe the pam umask module is the way to go according to
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
[opition] usergroups
If the user is not root, and the user ID is equal to the group ID,
and the username is the same as primary group name, the umask group
bits are set to be the same as owner bits (examples: 022 -> 002, 077
-> 007).
Regards
Bastien
>
> Cheers,
> harry
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/2010051710...@sbs288.lan
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimvlTUYnoDzFpMg3...@mail.gmail.com
Santiago Vila
> Santiago Vila <san...@unex.es> writes:
> > In either case, if we plan to set default umask in /etc/login.defs or
>
> /etc/login.defs is not read when I login to openssh server and it has
> "UseLogin" set to false. If I enable UseLogin then X11 forwarding
> stops working [1]. To me it seems that login.defs can not be the only
> place where umask is set.
Ok, what about PAM?
I would *really* like to drop umask setting from /etc/profile and rely on
something of lower level, be it login.defs, PAM or whatever.
What would be the steps required to be able to drop umask from /etc/profile?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1...@kolmogorov.unex.es
Timo Juhani Lindfors
> Ok, what about PAM?
"UsePAM no" is the default in openssh. I do not know if this is just
to reduce the attack surface.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
> On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
>
>> Santiago Vila <san...@unex.es> writes:
>> > In either case, if we plan to set default umask in /etc/login.defs or
>>
>> /etc/login.defs is not read when I login to openssh server and it has
>> "UseLogin" set to false. If I enable UseLogin then X11 forwarding
>> stops working [1]. To me it seems that login.defs can not be the only
>> place where umask is set.
>
> Ok, what about PAM?
>
> I would *really* like to drop umask setting from /etc/profile and rely on
> something of lower level, be it login.defs, PAM or whatever.
>
> What would be the steps required to be able to drop umask from /etc/profile?
See
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=002
And it will work
Regards
Bastien
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/alpine.DEB.1.10.1...@kolmogorov.unex.es
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTin1p37y8ZKe5YT8c...@mail.gmail.com
Reinhard Tartler
>> I believe the pam umask module is the way to go according to
>> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
>>
>> [opition] usergroups
>>
>> If the user is not root, and the user ID is equal to the group ID,
>> and the username is the same as primary group name, the umask group
>> bits are set to be the same as owner bits (examples: 022 -> 002, 077
>> -> 007).
>
Let's have a look at the source. Note that options->usergroups is set
iff the option "usergroups" is used.
,----[modules/pam_umask/pam_umask.c]
| /* Set the process nice, ulimit, and umask from the
| password file entry. */
| static void
| setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
| struct passwd *pw)
| {
| char *cp;
|
| if (options->usergroups)
| {
| /* if not root, and UID == GID, and username is the same as
| primary group name, set umask group bits to be the same as
| owner bits (examples: 022 -> 002, 077 -> 007). */
| if (pw->pw_uid != 0 && pw->pw_uid == pw->pw_gid)
| {
| struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
| if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
| {
| mode_t oldmask = umask (0777);
| umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
| }
| }
| }
|
| /* See if the GECOS field contains values for NICE, UMASK or ULIMIT. */
| for (cp = pw->pw_gecos; cp != NULL; cp = strchr (cp, ','))
| {
| if (*cp == ',')
| cp++;
|
| if (strncasecmp (cp, "umask=", 6) == 0)
| umask (strtol (cp + 6, NULL, 8) & 0777);
| else if (strncasecmp (cp, "pri=", 4) == 0)
| {
| errno = 0;
| if (nice (strtol (cp + 4, NULL, 10)) == -1 && errno != 0)
| {
| if (!options->silent || options->debug)
| pam_error (pamh, "nice failed: %m\n");
| pam_syslog (pamh, LOG_ERR, "nice failed: %m");
| }
| }
| else if (strncasecmp (cp, "ulimit=", 7) == 0)
| {
| struct rlimit rlimit_fsize;
| rlimit_fsize.rlim_cur = 512L * strtol (cp + 7, NULL, 10);
| rlimit_fsize.rlim_max = rlimit_fsize.rlim_cur;
| if (setrlimit (RLIMIT_FSIZE, &rlimit_fsize) == -1)
| {
| if (!options->silent || options->debug)
| pam_error (pamh, "setrlimit failed: %m\n");
| pam_syslog (pamh, LOG_ERR, "setrlimit failed: %m");
| }
| }
| }
| }
|
`----
This part of pam seems to match the documentation in pam_umask(8).
> And it was said in this thread that UID == GID is not always true with
> UPG. You only need to create a group for that to become false for users
> you would create afterwards.
I'd say if Debian's idea of UPG doesn't match pam's, we should either
change the pam implementation or the implementation of Debian's UPG
concept to match each other.
In any case, using pam_umask by default seems to the best approach so far.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87hbm64...@faui44a.informatik.uni-erlangen.de
Mike Hommey
> > And it was said in this thread that UID == GID is not always true with
> > UPG. You only need to create a group for that to become false for users
> > you would create afterwards.
>
> I'd say if Debian's idea of UPG doesn't match pam's, we should either
> change the pam implementation or the implementation of Debian's UPG
> concept to match each other.
There is no such thing as Debian's idea of UPG. There is simply the fact
that when you create a user with UPG, it uses the first uid and the
first gid available. It can happen that they don't match, in the
scenario I gave above. This applies to any distro, afaik.
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100517130...@glandium.org
Aaron Toponce
> There is no such thing as Debian's idea of UPG. There is simply the fact
> that when you create a user with UPG, it uses the first uid and the
> first gid available. It can happen that they don't match, in the
> scenario I gave above. This applies to any distro, afaik.
Yes, this is trivial. Create a group first, before creating a user, and
after creating users from there on, the UID and GID will be one off.
This is natural, and nothing to worry about. Unless you're obsessive
compulsive about the ids matching. :)
Santiago Vila
> Santiago Vila <san...@unex.es> writes:
> > Ok, what about PAM?
>
> "UsePAM no" is the default in openssh. I do not know if this is just
> to reduce the attack surface.
Grr. We are supposed to be system integrators, but how can we do that
if some parts of the system do not trust the other parts of the system?
That results in useless duplication of work.
Do I really have to put complex code in /etc/profile to use the old
umask when 1 <= uid <= 100?
Instead, we could consider as a bug that a "system user" wants to
login to the system at all.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1...@kolmogorov.unex.es
Philipp Kern
> Santiago Vila <san...@unex.es> writes:
>> Ok, what about PAM?
> "UsePAM no" is the default in openssh. I do not know if this is just
> to reduce the attack surface.
While that's true it's not the case for Debian openssh, its postinst adds
UsePAM yes to the configuration on upgrades.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnhv2ip3...@kelgar.0x539.de
Marvin Renich
> Let's have a look at the source. Note that options->usergroups is set
> iff the option "usergroups" is used.
>
> ,----[modules/pam_umask/pam_umask.c]
> | /* Set the process nice, ulimit, and umask from the
> | password file entry. */
> | static void
> | setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
> | struct passwd *pw)
> | {
> | char *cp;
> |
> | if (options->usergroups)
> | {
> | /* if not root, and UID == GID, and username is the same as
> | primary group name, set umask group bits to be the same as
> | owner bits (examples: 022 -> 002, 077 -> 007). */
> | if (pw->pw_uid != 0 && pw->pw_uid == pw->pw_gid)
> | {
> | struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
> | if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
> | {
> | mode_t oldmask = umask (0777);
> | umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
> | }
> | }
> | }
>
> This part of pam seems to match the documentation in pam_umask(8).
>
> > And it was said in this thread that UID == GID is not always true with
> > UPG. You only need to create a group for that to become false for users
> > you would create afterwards.
>
> I'd say if Debian's idea of UPG doesn't match pam's, we should either
> change the pam implementation or the implementation of Debian's UPG
> concept to match each other.
>
> In any case, using pam_umask by default seems to the best approach so far.
This looks like a bug in pam_umask. UPG has never guaranteed uid=gid.
I'll file a bug.
...Marvin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aaron Toponce
> This looks like a bug in pam_umask. UPG has never guaranteed uid=gid.
> I'll file a bug.
While the numerical ID might not match, the names should:
id -gn should equal id -un
After all, that is part of the definition of the UPG setup.
Peter Palfrader
> I guess I'm more or less curious why we're still using this outdated
> umask value with UPG. What would it take for Debian to update our
> default umask to match the UPG scheme? Is this doable for Sqeeze? Are
> there reasons for not making the switch?
The main problem with a default 002 umask, IMHO, is that as soon as you
copy your files from a host with 002 and usergroups to one without, or
untar a tarball created on a 002 host with usergroups on a system where
you don't have a usergroup, Bad Things can happen, depending on the
exact method you use to copy things.
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051714...@anguilla.noreply.org
Bernhard R. Link
> The main problem with a default 002 umask, IMHO, is that as soon as you
> copy your files from a host with 002 and usergroups to one without, or
> untar a tarball created on a 002 host with usergroups on a system where
> you don't have a usergroup, Bad Things can happen, depending on the
> exact method you use to copy things.
Every usual copy method should not have that problem (after all, umask
is about bits not to set with any new files explicitly created).
Only way to get something like that is cp -a or tar -xp.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010051715...@pcpool00.mathematik.uni-freiburg.de
Harald Braumann
> > On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
> >
> >> Will be done in base-files 5.4.
> >
> > I think that this change was done prematurely. There is still the
> > issue of a Debian system running in a non-UPG environment. And so far
> > I haven't seen a resolution for this point in the discussion.
>
> I believe the pam umask module is the way to go according to
> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
Fair enough ...
> [opition] usergroups
>
> If the user is not root, and the user ID is equal to the group ID,
> and the username is the same as primary group name, the umask group
> bits are set to be the same as owner bits (examples: 022 -> 002, 077
> -> 007).
... but that's the problem. User and group names/IDs are completely
independent from one another and from the group regime emplyed. By no
stretch of imagination can I see how you could deduce the group regime
of a system from those.
- you could have a UPG system but a mismatch of IDs -> wrong umask
- you could have a non-UPG system but a user's name and ID happen to
match those of the group -> wrong umask
- you could add more layers and check, e.g., if the user is the only
member in the group. but more users could be added later making the
first user's files writeable by those.
No matter how much clever logic you put in there, there is simply no
way to make this work reliably because it's based on wrong assumption.
Computer programmes work best when they are based on sound logic. Let's
not part with this tradition. Let's keep the umask fixed at 022 and let
the user change it if he wants.
Cheers,
harry
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aaron Toponce
> - you could have a UPG system but a mismatch of IDs -> wrong umask
ID numbers, yes. ID names, no. If the user name maches the group name,
IE: aaron = aaron, then the user matches the private group. If the match
is not made, then umask 0022 should be in play.
> - you could have a non-UPG system but a user's name and ID happen to
> match those of the group -> wrong umask
If the username matches the group name, then you have a UPG system.
Unless you created a user called "devel" and put him in the "devel"
group. Debian is not substitute for stupidity.
> - you could add more layers and check, e.g., if the user is the only
> member in the group. but more users could be added later making the
> first user's files writeable by those.
>
> No matter how much clever logic you put in there, there is simply no
> way to make this work reliably because it's based on wrong assumption.
There is no complex, additional layers to check. You only need to match
the user and group names. If they match, it's UPG. If they don't, it
isn't. Give me a realistic case where this would be problematic.
Harald Braumann
> On 05/17/2010 10:02 AM, Harald Braumann wrote:
> > - you could have a UPG system but a mismatch of IDs -> wrong umask
>
> ID numbers, yes. ID names, no. If the user name maches the group name,
> IE: aaron = aaron, then the user matches the private group. If the match
> is not made, then umask 0022 should be in play.
from pam_umask's description of the usergroups option:
If the user is not root, and the user ID is equal to the group ID, *and*
the username is the same as primary group name, the umask group bits
are set to be the same as owner bits (examples: 022 -> 002, 077 ->
007).
So if there is a mismatch of *either*, name or ID, then pam_umasks
detects a non-UPG system, while it might very well be all UPG. Also,
just because Debian's adduser happens to give the same name to the
user as well as to his private group, this is not necessarily true in
all system. You could have group names that are prefixed with "grp",
or whatever, but still have a perfectly valid UPG system.
> > - you could have a non-UPG system but a user's name and ID happen to
> > match those of the group -> wrong umask
>
> If the username matches the group name, then you have a UPG system.
And on what assumptions do you base this conclusion?
> Unless you created a user called "devel" and put him in the "devel"
> group. Debian is not substitute for stupidity.
How is that stupid? Users and groups are completely seperate name
spaces, so why would I care in a non-UPG system?
Aaron Toponce
> On Mon, May 17, 2010 at 10:14:28AM -0600, Aaron Toponce wrote:
>> On 05/17/2010 10:02 AM, Harald Braumann wrote:
>>> - you could have a UPG system but a mismatch of IDs -> wrong umask
>>
>> ID numbers, yes. ID names, no. If the user name maches the group name,
>> IE: aaron = aaron, then the user matches the private group. If the match
>> is not made, then umask 0022 should be in play.
>
> from pam_umask's description of the usergroups option:
>
> If the user is not root, and the user ID is equal to the group ID, *and*
> the username is the same as primary group name, the umask group bits
> are set to be the same as owner bits (examples: 022 -> 002, 077 ->
> 007).
>
> So if there is a mismatch of *either*, name or ID, then pam_umasks
> detects a non-UPG system, while it might very well be all UPG.
A bug in pam_umask.so that needs to be addressed (which I believe we've
already started addressing in this thread).
> Also,
> just because Debian's adduser happens to give the same name to the
> user as well as to his private group, this is not necessarily true in
> all system. You could have group names that are prefixed with "grp",
> or whatever, but still have a perfectly valid UPG system.
Can you produce a valid example? The definition of UPG is to create a
group name that is the same as the username. If the system in question
is using UPG, then there won't be any conflicts, unless the
admiinstrator tries creating a "adm" user, or something equally as unsound.
>> If the username matches the group name, then you have a UPG system.
>
> And on what assumptions do you base this conclusion?
This is how UPG works. A new user is added to the system, and a group of
the same name is also added to the system. This is fundamental to UPG.
>> Unless you created a user called "devel" and put him in the "devel"
>> group. Debian is not substitute for stupidity.
>
> How is that stupid? Users and groups are completely seperate name
> spaces, so why would I care in a non-UPG system?
If you're using a non-UPG system, then you don't care. Debian is
UPG-based, so your argument is invalid.
Christoph Anton Mitterer
unrelated software just to make UPG work (see
#581919).
Even the title of that "bug", "bad ownership or modes..." is
ridiculous... and proves what I've predicted before, namely that these
changes will compromise security (such a patch will also affect non UPG
systems).
Nevertheless,...
On Mon, 2010-05-17 at 11:04 -0600, Aaron Toponce wrote:
> If you're using a non-UPG system, then you don't care. Debian is
> UPG-based, so your argument is invalid.
You actually, have to care... at least if #581919 is "solved".
Cheers,
Chris.