UPG and the default umask

[Aaron Toponce]

Debian, by default, utilizes the user private group scheme (UPG). This
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,

[Julien Cristau]

Post by Aaron Toponce
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]

Post by Julien Cristau
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.

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]

Post by Aaron Toponce

Post by Julien Cristau
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.

Post by Aaron Toponce
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

[Aaron Toponce]

Post by Drake Wilson
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.

Post by Drake Wilson
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.

[Don Armstrong]

Post by Aaron Toponce
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

[Steve Langasek]

Post by Don Armstrong

Post by Aaron Toponce
If the default umask is '0002' on a UPG system,
then this checklist item doesn't need to be worried about.

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).

[Don Armstrong]

Post by Steve Langasek

Post by Don Armstrong

Post by Aaron Toponce
If the default umask is '0002' on a UPG system,
then this checklist item doesn't need to be worried about.

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

[Charles Plessy]

Post by Aaron Toponce

Post by Julien Cristau
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,

[Russ Allbery]

Post by Julien Cristau

Post by Aaron Toponce
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.

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.

[Aaron Toponce]

Post by 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.

Well said.

[Noah Meyerhans]

Post by Russ Allbery
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]

Hi,

Post by Noah Meyerhans
Right, our default setup is a strange and basically meaningless blend of
two different approaches to user primary groups.

[...]

Post by Noah Meyerhans
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.

[..]

Post by Noah Meyerhans
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

[Charles Plessy]

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/***@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/***@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,

[Philipp Kern]

Post by Charles Plessy
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

Kind regards,
Philipp Kern

[Andrei Popescu]

Post by Philipp Kern

Post by Charles Plessy
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

How about a message on debian-security-announce ?

Regards,
Andrei

[Lucas Nussbaum]

Post by Philipp Kern

Post by Charles Plessy
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

[Philipp Kern]

Post by Lucas Nussbaum

Post by Philipp Kern

Post by Charles Plessy
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

[Russ Allbery]

Post by Philipp Kern

Post by Lucas Nussbaum

Post by Philipp Kern
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.

[Aaron Toponce]

Post by Philipp Kern

Post by Charles Plessy
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]

Post by Aaron Toponce

Post by Philipp Kern
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

Post by Aaron Toponce
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.

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.

[Santiago Vila]

Post by Charles Plessy
found 248140 5.3
thanks
Dear Santiago,
You probably have seen the discussion about user private groups on
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
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.

Post by Charles Plessy
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.

[Aaron Toponce]

Post by Santiago Vila
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]

Post by Aaron Toponce

Post by Santiago Vila
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 <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B

[Vincent Danjean]

Post by Aaron Toponce

Post by Santiago Vila
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:
***@eyak:~$ chmod -Rv g+w .ssh/authorized_keys
***@eyak:~$ ssh localhost
***@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

***@eyak:~$ chmod -Rv g-w .ssh/authorized_keys
le mode de « .ssh/authorized_keys » a été modifié en 0644 (rw-r--r--).
***@eyak:~$ ssh localhost
You have mail.
Last login: Tue May 11 17:10:30 2010
***@eyak:~$

My system is in UPG but I was using default umask 022

Regards
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 ***@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

[Joey Hess]

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
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.

[Andreas Hemel]

Post by Joey Hess

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
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?


Andreas

[Santiago Vila]

Post by Andreas Hemel

Post by Joey Hess

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
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.

[Santiago Vila]

Post by Joey Hess

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
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.

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

[Klaus Ethgen]

Post by Santiago Vila
I remember that procmail had a similar problem, and the author
1999/03/02: v3.12
- 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 <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B

[Joey Hess]

Post by Klaus Ethgen
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.

[Christoph Anton Mitterer]

Post by Joey Hess
Your typical program with a dotfile relies on the user
choosing a safe combination of umask and directory permissions for its
security.

As you say,... it "relies on the user"...

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.

[Andreas Metzler]

Santiago Vila <***@unex.es> wrote:
[...]

Post by 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
1999/03/02: v3.12
- 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

[Christoph Anton Mitterer]

Post by Andreas Metzler
#2 UPG with umask 022 is useless.

Why is it?
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.

[Andrei Popescu]

Post by Christoph Anton Mitterer

Post by Andreas Metzler
#2 UPG with umask 022 is useless.

Why is it?
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.

Why is an own group needed for this? Can't the admin just create groups
as needed where both users shall belong?

Regards,
Andrei

[Christoph Anton Mitterer]

Post by Andrei Popescu
Why is an own group needed for this? Can't the admin just create groups
as needed where both users shall belong?

Well but that's always possible isn't it? So one could drop the concept
of UPGs completely...


Cheers,
Chris.

[Andrei Popescu]

Post by Christoph Anton Mitterer

Post by Andrei Popescu
Why is an own group needed for this? Can't the admin just create groups
as needed where both users shall belong?

Well but that's always possible isn't it? So one could drop the concept
of UPGs completely...

Sure, it makes sense with a default umask of 0022 ;)

Regards,
Andrei

[Thomas Hochstein]

Post by Christoph Anton Mitterer

Post by Andreas Metzler
#2 UPG with umask 022 is useless.

Why is it?

See <http://lists.debian.org/debian-devel/2010/05/msg00315.html>.

[Don Armstrong]

Post by Andreas Metzler
#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.

[Drake Wilson]

Post by Don Armstrong
You don't need to detect UPG setups with 100% reliability; you can

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

[Andreas Metzler]

Post by Drake Wilson

Post by Don Armstrong
You don't need to detect UPG setups with 100% reliability; you can

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

[Joey Hess]

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
le mode de « .ssh/authorized_keys » a été modifié en 0644 (rw-r--r--).
You have mail.
Last login: Tue May 11 17:10:30 2010
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.

[Vincent Danjean]

Post by Joey Hess

Post by Vincent Danjean
I'm happy with this move. However, there is still an interaction with ssh
May 14 09:42:17 eyak sshd[1618]: Authentication refused: bad ownership or modes for file /home/vdanjean/.ssh/authorized_keys
le mode de « .ssh/authorized_keys » a été modifié en 0644 (rw-r--r--).
You have mail.
Last login: Tue May 11 17:10:30 2010
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.

Somethink is wrong here. Should 314347 be reopened ?

***@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
***@eyak:~$ cat /etc/group /etc/passwd | grep '^vdanjean'
vdanjean:x:1000:
vdanjean:x:1000:1000:Vincent Danjean,,,:/home/vdanjean:/bin/bash
***@eyak:~$
--
Vincent Danjean GPG key ID 0x9D025E87 ***@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

[Aaron Toponce]

Post by Vincent Danjean
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.

[Vincent Danjean]

Post by Aaron Toponce

Post by Vincent Danjean
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

[Petter Reinholdtsen]

[Santiago Vila]

Post by 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,

[Charles Plessy]

Post by Santiago Vila
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:

http://wiki.debian.org/umask

Have a nice day,

[Harald Braumann]

Post by Santiago Vila
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

[Bastien ROUCARIES]

Post by Harald Braumann

Post by Santiago Vila
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

Post by Harald Braumann
Cheers,
harry
--

[Mike Hommey]

Post by Bastien ROUCARIES

Post by Harald Braumann

Post by Santiago Vila
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).

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

[Reinhard Tartler]

Post by Mike Hommey

Post by Bastien ROUCARIES
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).

Post by 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.

In any case, using pam_umask by default seems to the best approach so far.

[Mike Hommey]

Post by Reinhard Tartler

Post by 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

[Aaron Toponce]

Post by Mike Hommey
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. :)

[Marvin Renich]

Post by Reinhard Tartler
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).

Post by 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.
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

[Aaron Toponce]

Post by Marvin Renich
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.

[Harald Braumann]

Post by Bastien ROUCARIES

Post by Harald Braumann

Post by Santiago Vila
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 ...

Post by Bastien ROUCARIES
[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

[Aaron Toponce]

Post by Harald Braumann
- 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.

Post by Harald Braumann
- 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.

Post by Harald Braumann
- 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]

Post by Aaron Toponce

Post by Harald Braumann
- 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.

Post by Aaron Toponce

Post by Harald Braumann
- 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?

Post by Aaron Toponce
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?

harry

[Aaron Toponce]

Post by Harald Braumann

Post by Aaron Toponce

Post by Harald Braumann
- 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.

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).

Post by Harald Braumann
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.

Post by Harald Braumann

Post by Aaron Toponce
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.

Post by Harald Braumann

Post by Aaron Toponce
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]

As far as I understood,... you guys are already starting to patch
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,...

Post by Aaron Toponce
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.

[Stefano Zacchiroli]

Post by 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.

<snip>

Post by Russ Allbery
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.

[Willi Mann]

Hi!

Post by Russ Allbery
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

[Russ Allbery]

Post by Willi Mann

Post by Russ Allbery
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.

[Roger Leigh]

Post by Russ Allbery

Post by Willi Mann

Post by Russ Allbery
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.

[Russ Allbery]

Post by Roger Leigh

Post by Russ Allbery
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.

[Vincent Bernat]

OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 15 mai 2010,

Post by Russ Allbery

Post by Willi Mann
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.

[Harald Braumann]

Post by Russ Allbery

Post by Willi Mann

Post by Russ Allbery
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

[The Fungi]

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.

[Russ Allbery]

Post by The Fungi

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.

[Harald Braumann]

Post by The Fungi

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

[Felipe Sateler]

Post by Harald Braumann
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

[Russ Allbery]

Post by 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?

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.

[Felipe Sateler]

Post by Russ Allbery

Post by 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?

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.

[Russ Allbery]

Post by Felipe Sateler
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.

[Brian May]

Post by Russ Allbery
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?

[Russ Allbery]

Post by Brian May
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. :)

[Thomas Hochstein]

Post by Felipe Sateler
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

[Christoph Anton Mitterer]

Post by Felipe Sateler
Is there a reason to support non-UPG systems?

Not to force users to use anything that they don't want?


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.

[Holger Levsen]

Hi,
how about you file bugs _with patches_? Talk is cheap.


cheers,
Holger

[Christoph Anton Mitterer]

Post by Holger Levsen
how about you file bugs _with patches_? Talk is cheap.

Well the only patches I could write with pure conscience would be:
- 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.

[Holger Levsen]

Post by Christoph Anton Mitterer
But I guess non of them wouldn't be received enthusiastically, would they?

you suggested something else in your previous mail...

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 10:22 AM, Christoph Anton Mitterer

Post by Christoph Anton Mitterer

Post by Felipe Sateler
Is there a reason to support non-UPG systems?

Not to force users to use anything that they don't want?
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?
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.
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?

See below libpam umask could be used for this task and extended if needed.

Post by Christoph Anton Mitterer
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
# 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
# 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

[Aaron Toponce]

Post by Willi Mann
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

[Russ Allbery]

Post by Aaron Toponce
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.)

[Aaron Toponce]

Post by Russ Allbery
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]

Post by Russ Allbery

Post by Aaron Toponce
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.

[Aaron Toponce]

Post by Santiago Vila
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?

[Timo Juhani Lindfors]

Post by Santiago Vila
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."

[Santiago Vila]

Post by Timo Juhani Lindfors

Post by Santiago Vila
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?

[Timo Juhani Lindfors]

Post by Santiago Vila
Ok, what about PAM?

"UsePAM no" is the default in openssh. I do not know if this is just
to reduce the attack surface.

[Santiago Vila]

Post by Timo Juhani Lindfors

Post by Santiago Vila
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.

[Philipp Kern]

Post by Timo Juhani Lindfors

Post by Santiago Vila
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

[Bastien ROUCARIES]

Post by Santiago Vila

Post by Timo Juhani Lindfors

Post by Santiago Vila
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

Post by Santiago Vila
--

[Klaus Ethgen]

Post by 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.

Post by Aaron Toponce
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!

Post by Aaron Toponce
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 <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B

[Aaron Toponce]

Post by Klaus Ethgen
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.

Post by Klaus Ethgen
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]

Hi,

Post by Aaron Toponce

Post by Klaus Ethgen
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!

Post by Aaron Toponce
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!

Post by Aaron Toponce
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.

Post by Aaron Toponce
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 <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B

[Aaron Toponce]

Post by Klaus Ethgen
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.

Post by Klaus Ethgen

Post by Aaron Toponce
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?

Post by Klaus Ethgen
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.

Post by Klaus Ethgen
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]

Hi,

Post by Aaron Toponce

Post by Klaus Ethgen
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. :-)

Post by Aaron Toponce

Post by Klaus Ethgen

Post by Aaron Toponce
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.

Post by Aaron Toponce

Post by Klaus Ethgen
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.

Post by Aaron Toponce
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!

Post by Aaron Toponce
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.

Post by Aaron Toponce
My argument is about the group permission, not other.

Right, mine too.

Post by Aaron Toponce

Post by Klaus Ethgen
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.

Post by Aaron Toponce
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.

Post by Aaron Toponce
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.

Post by Aaron Toponce
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.

Post by Aaron Toponce
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 <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B

[Peter Palfrader]

Post by Aaron Toponce
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.

[Bernhard R. Link]

Post by Peter Palfrader
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