Re: UPG and the default umask

[Ben Finney]

Michael Banck  writes:

> On Fri, May 21, 2010 at 04:19:02PM +1000, Ben Finney wrote:
> > Out of interest
[…]

> Please take this conversation to -project or elsewhere, it does not
> belong on -devel.

Fair enough, I accept the rebuke gratefully.

-- 
 \“The restriction of knowledge to an elite group destroys the |
  `\   spirit of society and leads to its intellectual |
_o__)impoverishment.” —Albert Einstein |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkztfy31@benfinney.id.au

Re: UPG and the default umask

[Michael Banck]

On Fri, May 21, 2010 at 04:19:02PM +1000, Ben Finney wrote:
> Mike Bird  writes:
> 
> > Those of us who actually administer Linux systems realize that the
> > proponents of this change are (a) way out of their depth so that (b)
> > they cannot forsee the consequences of their actions yet (c) they have
> > the power to carry their actions through and (d) they haven't listened
> > to reason yet.
> 
> Out of interest, how would you propose an independent observer should
> distinguish between these two cases:
> 
> * The package maintainers respond to specific expressed complaints,
>   then ignore the complaints and fail to listen to reason.
> 
> * The package maintainers respond to specific expressed complaints,
>   then consider the complaints and reject them on the basis of reason.
> 
> How would the independent observer tell which has occurred?

Please take this conversation to -project or elsewhere, it does not
belong on -devel.


Thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100521082347.ga30...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Ben Finney]

Mike Bird  writes:

> Those of us who actually administer Linux systems realize that the
> proponents of this change are (a) way out of their depth so that (b)
> they cannot forsee the consequences of their actions yet (c) they have
> the power to carry their actions through and (d) they haven't listened
> to reason yet.

Out of interest, how would you propose an independent observer should
distinguish between these two cases:

* The package maintainers respond to specific expressed complaints,
  then ignore the complaints and fail to listen to reason.

* The package maintainers respond to specific expressed complaints,
  then consider the complaints and reject them on the basis of reason.

How would the independent observer tell which has occurred?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but if we have nothing to fear but fear itself, why does |
_o__) Elanore Roosevelt wear that spooky mask?” —_Pinky and The Brain_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874oi1hj55@benfinney.id.au

Re: UPG and the default umask

[Petter Reinholdtsen]

[Mike Bird]
> Those of us who actually administer Linux systems realize that the
> proponents of this change are (a) way out of their depth so that (b)
> they cannot forsee the consequences of their actions yet (c) they
> have the power to carry their actions through and (d) they haven't
> listened to reason yet.

Must be nice to be so confident about the errors of others.

Anyway, just as an interesting comment, this is what the RHEL 5 manual
have to say about user private groups and the default in RedHat and
Fedora:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-users-groups-private-groups.html
 >.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2flocg923od@login1.uio.no

Re: UPG and the default umask

[Mike Bird]

On Thu May 20 2010 07:24:16 Michael Banck wrote:
> The problem is that most of your mails started with "OMG Debian will
> compromise security, you all suck" or a paraphrasing thereof, so most
> people didn't bother to read your mails in full and never actually read
> a reasonable argument why the default umask should not be changed for
> UPG setups.

Michael,

Those of us who actually administer Linux systems realize
that the proponents of this change are (a) way out of their
depth so that (b) they cannot forsee the consequences of
their actions yet (c) they have the power to carry their
actions through and (d) they haven't listened to reason yet.

So we just watch and laugh sadly and pray that we can keep
our systems secure.  Debian has survived worse and it will
survive this mess too.

--Mike Bird


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005201843.00651.mgb-deb...@yosemite.net

Re: UPG and the default umask

[Roger Lynn]

On 19/05/10 22:20, Christoph Anton Mitterer wrote:
> btw: What happened to the idea of movin umask completely away from
> /etc/profile?
> I mean regardless of the discussion about UPGs and which value is the
> "best" default for umask, I found it to be a good idea to drop it there.

This is a good question. When I was changing my umask to 0002 a few
months ago web searches told me to look in login.defs, which told me to
use pam. So eventually I worked out how to change the umask in pam, but
it still didn't have any affect. It was only have further searching that
I discovered it was being overridden by /etc/profile.

Roger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf5bb38.6050...@rilynn.me.uk

Re: UPG and the default umask

[Russ Allbery]

Roger Leigh  writes:
> On 20/05/2010 18:30, Russ Allbery wrote:

>> You can't move the static reserved space: it contains statically
>> assigned UIDs.  :)  That's the whole point of it.  We could change
>> where we're assigning future static UIDs and GIDs from, but I'm not
>> sure it's worth the effort given that there's always going to have to
>> be a legacy reserved space for the ones that were already assigned.

> Do we have any actual users of this space?  I didn't see anything in
> Policy.  Is there a central database listing the assignments?  If so,
> where may it be found?

Steve got this part.

>>> Additionally, user nobody would then be in the middle of the user
>>> range; it could be shifted back to the end of the 32-bit range.

>> I don't think it's a good idea to let people assign 65535 to a regular
>> user.  That's been hardcoded as nobody in a vast number of UNIX systems
>> for decades.  Reusing that UID for other purposes in any sort of shared
>> infrastructure is almost certain to cause problems.

> 65534 is the UID for nobody.

Sorry, I meant 66534.  You're of course correct with 66535; you can't use
that on 16-bit UID systems, but otherwise it shouldn't be as much of an
issue.

> Anything using the UID for nobody should be getting it through the libc
> functions as for any other user; does any code actually hardcode 65534?
> IMO that's a bug if so.

Different sort of hard-code.  It's in tons of existing /etc/passwd files,
and giving another user the same UID as nobody (such as, for instance, a
mix of LDAP and local /etc/passwd data stores) can produce some nasty
security exposures depending on how nobody is being used.

> Given that nobody can't create files except for in /tmp and other
> world-writable locations, there shouldn't be any issues with changing
> the UID/GID since nothing in the filesystem should be owned by them.

By default, assuming use only of packages in Debian and no changes by
local administrators.  Those aren't good assumptions.

Changing a UID is a very big and disruptive change, and remember that a
lot of sites share UIDs site-wide.

> The main justification I would have for this change is that keeping the
> old 16-bit-constrained assignments fragments the 32-bit range space
> unnecessarily.  For checks such as being discussed, having a contiguous
> user range makes things much simpler for both us and admins.

I agree with Steve: the best way to provide a contiguous range is to start
in 32-bit space above our existing reservations.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk5m71it@windlord.stanford.edu

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 20:43, Steve Langasek wrote:

On Thu, May 20, 2010 at 08:31:36PM +0100, Roger Leigh wrote:

Do we have any actual users of this space?  I didn't see anything in
Policy.  Is there a central database listing the assignments?  If
so, where may it be found?


/usr/share/doc/base-passwd/README


Thanks.  Looking at the list, there's only 10 packages in total.  9 
create just one user/group, and one (qmail, which AFIACT isn't even in 
Debian) creates six.  I'm unsure why these 9 packages need a static 
allocation, given that every other service just creates/removes them 
dynamically.  Given the miniscule usage of this reserved range, is 
static allocation justifiable?



The main justification I would have for this change is that keeping
the old 16-bit-constrained assignments fragments the 32-bit range
space unnecessarily.  For checks such as being discussed, having a
contiguous user range makes things much simpler for both us and
admins.  I accept that we can't change things for existing systems
where these are already being used, but it sucks to be stuck with a
16-bit legacy for evermore even for new installs.


I don't think it's practical to ever get rid of the legacy UID range
fragmentation in the 16-bit space.  Better would be to plan a transition to
where we start numbering new user accounts from 65536 by default, instead of
from 1000.


Something probably best left until after Squeeze!  I think the simple 
check we have now will be robust enough until after then.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf5976a.8080...@codelibre.net

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 20:44, Bastien ROUCARIÈS wrote:


"Roger Leigh"  a écrit :



The main justification I would have for this change is that keeping the
old 16-bit-constrained assignments fragments the 32-bit range space
unnecessarily.  For checks such as being discussed, having a contiguous
user range makes things much simpler for both us and admins.  I accept
that we can't change things for existing systems where these are already
being used, but it sucks to be stuck with a 16-bit legacy for evermore
even for new installs.



Does it will break reading file from uid16 filesystem?


This transition took place 10 years ago in the kernel and has been 
supported by all the mainstream filesystems since then; the minor ones 
may have also been fixed up.  This was fixed years ago, the most recent 
being fixing diskquotas.  Should be no problems in 2010!



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf59722.3080...@codelibre.net

Re: UPG and the default umask

[Bastien ROUCARIÈS]

"Roger Leigh"  a écrit :

>On 20/05/2010 18:30, Russ Allbery wrote:
>> Roger Leigh  writes:
>>
>>> If all current Debian systems support a 32-bit UID and GID range, then
>>> it would be great if we could amend Policy to move the reserved ranges
>>> to the end of the 32-bit range rather than being at the end of the
>>> 16-bit range.  This would give a vast contiguous user range (4294931294
>>> UIDs using the scheme below)
>>
>> You can't move the static reserved space: it contains statically assigned
>> UIDs.  :)  That's the whole point of it.  We could change where we're
>> assigning future static UIDs and GIDs from, but I'm not sure it's worth
>> the effort given that there's always going to have to be a legacy reserved
>> space for the ones that were already assigned.
>
>Do we have any actual users of this space?  I didn't see anything in 
>Policy.  Is there a central database listing the assignments?  If so, 
>where may it be found?
>
>In the absence of any existing static assignments, I don't see any
>issue with moving the range.  If there are assignments, could these
>not be moved for new installs?
>
>>> Additionally, user nobody would then be in the middle of the user
>>> range; it could be shifted back to the end of the 32-bit range.
>>
>> I don't think it's a good idea to let people assign 65535 to a regular
>> user.  That's been hardcoded as nobody in a vast number of UNIX systems
>> for decades.  Reusing that UID for other purposes in any sort of shared
>> infrastructure is almost certain to cause problems.
>
>65534 is the UID for nobody.  Anything using the UID for nobody should 
>be getting it through the libc functions as for any other user; does any 
>code actually hardcode 65534?  IMO that's a bug if so.  Given that 
>nobody can't create files except for in /tmp and other world-writable 
>locations, there shouldn't be any issues with changing the UID/GID since 
>nothing in the filesystem should be owned by them.  A quick check on my 
>system shows just two locations:
>
>drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
>drwxr-se-x root nogroup 63488 May  2 01:04 /usr/lib/kde4/libexec/kdesud
>
>The first is totally pointless (bug filed), it could just be root:root 
>and be even more safe.  The latter looks OK but should we really be 
>having a file owned by nogroup in the filesystem at all on general 
>principle?
>
>Regarding 65535: Does any software actually hardcode the number 65535? 
>Given that its only use is as an error return (-1) for uid_t and this is 
>now a uint32_t any code hardcoding this value is already broken.
>
>The main justification I would have for this change is that keeping the 
>old 16-bit-constrained assignments fragments the 32-bit range space 
>unnecessarily.  For checks such as being discussed, having a contiguous 
>user range makes things much simpler for both us and admins.  I accept 
>that we can't change things for existing systems where these are already 
>being used, but it sucks to be stuck with a 16-bit legacy for evermore 
>even for new installs.


Does it will break reading file from uid16 filesystem?

Regards

Bastien
>
>Regards,
>Roger
>
>
>-- 
>To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>Archive: http://lists.debian.org/4bf58e18.3030...@codelibre.net
>

Re: UPG and the default umask

[Steve Langasek]

On Thu, May 20, 2010 at 08:31:36PM +0100, Roger Leigh wrote:
> Do we have any actual users of this space?  I didn't see anything in
> Policy.  Is there a central database listing the assignments?  If
> so, where may it be found?

/usr/share/doc/base-passwd/README

> The main justification I would have for this change is that keeping
> the old 16-bit-constrained assignments fragments the 32-bit range
> space unnecessarily.  For checks such as being discussed, having a
> contiguous user range makes things much simpler for both us and
> admins.  I accept that we can't change things for existing systems
> where these are already being used, but it sucks to be stuck with a
> 16-bit legacy for evermore even for new installs.

I don't think it's practical to ever get rid of the legacy UID range
fragmentation in the 16-bit space.  Better would be to plan a transition to
where we start numbering new user accounts from 65536 by default, instead of
from 1000.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 18:30, Russ Allbery wrote:

Roger Leigh  writes:


If all current Debian systems support a 32-bit UID and GID range, then
it would be great if we could amend Policy to move the reserved ranges
to the end of the 32-bit range rather than being at the end of the
16-bit range.  This would give a vast contiguous user range (4294931294
UIDs using the scheme below)


You can't move the static reserved space: it contains statically assigned
UIDs.  :)  That's the whole point of it.  We could change where we're
assigning future static UIDs and GIDs from, but I'm not sure it's worth
the effort given that there's always going to have to be a legacy reserved
space for the ones that were already assigned.


Do we have any actual users of this space?  I didn't see anything in 
Policy.  Is there a central database listing the assignments?  If so, 
where may it be found?


In the absence of any existing static assignments, I don't see any
issue with moving the range.  If there are assignments, could these
not be moved for new installs?


Additionally, user nobody would then be in the middle of the user
range; it could be shifted back to the end of the 32-bit range.


I don't think it's a good idea to let people assign 65535 to a regular
user.  That's been hardcoded as nobody in a vast number of UNIX systems
for decades.  Reusing that UID for other purposes in any sort of shared
infrastructure is almost certain to cause problems.


65534 is the UID for nobody.  Anything using the UID for nobody should 
be getting it through the libc functions as for any other user; does any 
code actually hardcode 65534?  IMO that's a bug if so.  Given that 
nobody can't create files except for in /tmp and other world-writable 
locations, there shouldn't be any issues with changing the UID/GID since 
nothing in the filesystem should be owned by them.  A quick check on my 
system shows just two locations:


drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
drwxr-se-x root nogroup 63488 May  2 01:04 /usr/lib/kde4/libexec/kdesud

The first is totally pointless (bug filed), it could just be root:root 
and be even more safe.  The latter looks OK but should we really be 
having a file owned by nogroup in the filesystem at all on general 
principle?


Regarding 65535: Does any software actually hardcode the number 65535? 
Given that its only use is as an error return (-1) for uid_t and this is 
now a uint32_t any code hardcoding this value is already broken.


The main justification I would have for this change is that keeping the 
old 16-bit-constrained assignments fragments the 32-bit range space 
unnecessarily.  For checks such as being discussed, having a contiguous 
user range makes things much simpler for both us and admins.  I accept 
that we can't change things for existing systems where these are already 
being used, but it sucks to be stuck with a 16-bit legacy for evermore 
even for new installs.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf58e18.3030...@codelibre.net

Re: UPG and the default umask

[Russ Allbery]

Roger Leigh  writes:

> If all current Debian systems support a 32-bit UID and GID range, then
> it would be great if we could amend Policy to move the reserved ranges
> to the end of the 32-bit range rather than being at the end of the
> 16-bit range.  This would give a vast contiguous user range (4294931294
> UIDs using the scheme below)

You can't move the static reserved space: it contains statically assigned
UIDs.  :)  That's the whole point of it.  We could change where we're
assigning future static UIDs and GIDs from, but I'm not sure it's worth
the effort given that there's always going to have to be a legacy reserved
space for the ones that were already assigned.

> Additionally, user nobody would then be in the middle of the user
> range; it could be shifted back to the end of the 32-bit range.

I don't think it's a good idea to let people assign 65535 to a regular
user.  That's been hardcoded as nobody in a vast number of UNIX systems
for decades.  Reusing that UID for other purposes in any sort of shared
infrastructure is almost certain to cause problems.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hmyiip8@windlord.stanford.edu

Re: UPG and the default umask

[Roger Leigh]

On Thu, May 20, 2010 at 02:34:30PM +0200, Santiago Vila wrote:
> On Thu, 20 May 2010, Raphael Hertzog wrote:
> 
> > Hi,
> > 
> > On Thu, 20 May 2010, Santiago Vila wrote:
> > > So I agree that the sane thing to do here is, at least, to use the
> > > same default range as /etc/adduser.conf (which in turn is the range
> > > defined by policy).
> > > 
> > > I've just modified base-files accordingly to use the UID range 1000-2.
> > 
> > I'm not sure this makes lots of sense.
> > 
> > hert...@alioth:~$ id -u maximilinux-guest
> > 220227
> > 
> > There are many installations out there with large numbers of users that
> > simply can't respect the ranges set by the policy.
> > 
> > I would simply use a minimum of 500 or 1000 to differentiate system users
> > from normal users. adduser is not a required step to create accounts when
> > you manage your account database in LDAP/PostgreSQL (or whatever else).
> > 
> > Having a different behaviour betweent accounts simply because some are
> > above the maximal limits and some are below would be counter productive.
> > 
> > The policy was written when uid/gid were only 16 bits but our systems cope
> > with greater number of users nowadays... maybe the policy should be
> > revised on that point.
> 
> Yes, maybe we should modify policy.
> 
> But for now, current policy says UIDs over 3 are "reserved", which means
> they might or might not be "ordinary user accounts".
> 
> Those who do not use "adduser" because "they know that they are doing"
> will surely be able to change /etc/profile if the default one is not
> suitable for them, as it happens with every default value in the system.
> 
> If we don't follow policy closely here, we can't claim that the umask
> change does only affect "ordinary user accounts" (which is what I
> think the release notes for squeeze will say).
> 
> So, I'm just providing a default which is consistent with other
> defaults in the system and also with policy.

I think using the user range defined by policy is fine for now.  At worst,
sites using the "reserved" and "reserved for Debian" ranges will get an
0022 umask for user accounts in this range until they change the user
range, i.e. no decrease in security.

> If by doing so we realize as a result that policy should be modified,
> let us modify policy then.

If all current Debian systems support a 32-bit UID and GID range, then
it would be great if we could amend Policy to move the reserved ranges
to the end of the 32-bit range rather than being at the end of the
16-bit range.  This would give a vast contiguous user range (4294931294
UIDs using the scheme below)

Likewise, 65535 is no longer a prohibited value; it's now (2^32)-1 =
4294967295, so Policy could also amend this restriction.

Additionally, user nobody would then be in the middle of the user
range; it could be shifted back to the end of the 32-bit range.


Suggestion for Policy:

0-99: Debian Global
100-999: Debian Dynamic
1000-4294932293: Users
[65534: nobody; could be moved to 4294967294 for new installs?]

4294932294-4294962293: Reserved
4294962294-4294967293: Debian Static Reserved
4294967294: nobody [new]
4294967295: (uid_t)(-1) == (gid_t)(-1) must not be used, because it is the 
error return sentinel value.

The ranges can be adjusted to make them tider if desired; this is just
adjusting the ranges as above, and drops the final (tiny) reserved range.
For example:

429490-429496: Reserved (6, was 30534)
429496-4294967293: Debian Static Reserved (7293, was 5000)


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Michael Banck]

On Wed, May 19, 2010 at 09:48:41PM +, Christoph Anton Mitterer wrote:
> On Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce
> 
> wrote:
> > You've only mentioned that SSH won't operate if the write bit is set on
> > the keys or anything under the ~/.ssh/ directory. Can you explain how an
> > ssh client failing to connect to an external ssh server because of the
> > umask is compromising security on the system?
> 
> Simply read the mails and those from the other critics again, it's not
> only annoying for myself to repeat things over and over again but also for
> everybody else to read it again.
> Nevertheless just saying "everything's fine" or "you only complained about
> ssh" won't really solve the issues, but just help to wave these changes
> through.

The problem is that most of your mails started with "OMG Debian will
compromise security, you all suck" or a paraphrasing thereof, so most
people didn't bother to read your mails in full and never actually read
a reasonable argument why the default umask should not be changed for
UPG setups.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100520142416.gb22...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Michael Banck]

On Thu, May 20, 2010 at 02:34:30PM +0200, Santiago Vila wrote:
> But for now, current policy says UIDs over 3 are "reserved", which means
> they might or might not be "ordinary user accounts".
> 
> Those who do not use "adduser" because "they know that they are doing"
> will surely be able to change /etc/profile if the default one is not
> suitable for them, as it happens with every default value in the system.
> 
> If we don't follow policy closely here, we can't claim that the umask
> change does only affect "ordinary user accounts" (which is what I
> think the release notes for squeeze will say).

Wouldn't the other way round mean that we cannot claim that the umask
changes will affect *all* "ordinary user account"?


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100520142149.ga22...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Bastien ROUCARIES]

On Tue, May 18, 2010 at 4:16 PM, Harald Braumann  wrote:
> On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote:
>> On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
>> > On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
>> >> On 2010-05-18, Christoph Anton Mitterer  wrote:
>> >> > Not to speak about, that UPG is anyway a questionable abuse of the
>> >> > user/group concept.
>> >> >
>> >> > Neither to speak about the fact, that in the 17 years debian exists
>> >> > now,... no majority missed that "feature" (apparently).
>> >>
>> >> So you present that as universal facts as if you've booked the truth
>> >> (possibly a bad translation of a German saying).
>> >>
>> >> I think that feature is useful for all those who don't want to mess
>> >> with ACLs.  If you are not allowed to use ACLs and don't have UPG
>> >> with sane umasks collaboration is painful (see e.g. Debian infrastrure
>> >> with all users being in group Debian and default umask 0022 which
>> >> leads to wrong permissions in setgid directories, with ACLs being
>> >> disallowed).  So indeed I got a script which does newgrp and
>> >> setting the umask for me which I run whenever I want to do release
>> >> tasks.  But it would be more sane if the user wouldn't have to
>> >> care about that.
>> >
>> > Let me quote from the comments in /etc/login.defs:
>> >
>> > # 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.
>> >
>> > And that's exactly the problem: there is no one-size-fits-all
>> > for the umask. Yes, for collaboration in a setgid directory you'd have
>> > to use 002 and thanks to UPG this is possible without compromising
>> > security. But I consider this just a special case. There are
>> > cases where Debian runs in a non-UPG environment, where you can't use
>> > that umask. And I don't think that's uncommon. Think of a mixed
>> > environment with Windows, where you might have a samba domain in LDAP. And
>> > last time I checked, the smbldap-tools didn't support UPG.
>>
>> Could you fill a bug report against smbldap-tools ?
>
> There is already an upstream bug [0], but even if it get's
> implemented, that wouldn't magically change all systems out there
> running non-UPG
>
>>
>>
>> > So whatever value is used as the default, half of the users will have
>> > to change it anyway, to fit their needs. And in such a case, where
>> > there is no single optimal value, I'd rather have the most
>> > conservative as default.
>> >
>> > If the umask is 022 and you create a setgid
>> > directory and forget to change the umask, you will quickly realise
>> > that things are not working as expected and fix it. If the umask is
>> > 002 and you add your Debian system to a non-UPG environment and forget
>> > to change the umask, things will still work perfectly but you put all
>> > your files at risk and might not even realise it until it is too
>> > late.
>>
>> Why not add a security dialog and assistant for installing and
>> upgrading the system?
>> It will ease the transition and fit allt the need, documenting
>> drawbacks and advantages of each scheme ?
>
> A umask of 022 is the right choice for most people and at least
> doesn't put the others at risk. Everyone, who knows what a setgid
> directory is and how it works, will also know, that there are certain
> requirements on the umask. And the others really don't care, as long
> as their security is not compromised.
>
> There is really no need to force everyone to make a useless decision,
> just for the sake of a change to make life of a specific minority easier.
>
> Cheers,
> harry
>
> [0] http://gna.org/support/?2040

Reported as #582388

Thanks


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik2ugx9aqzveuqjfiko6oqqaq6rcyhzoz_ea...@mail.gmail.com

Re: UPG and the default umask

[Marvin Renich]

* Bastien ROUCARIES  [100520 08:30]:
> reopen 315089
> thanks
> 
> Closed by maintener and reopened, if we use libpam for umask it could
> be even raised to RC critical, so please correct this behavior, report
> upstream. I agree that it could be misleading for other distro in this
> case, please add a newoption like useupg.
> 
> Thanks
> 
> Bastien

I have forwarded this upstream.
https://sourceforge.net/tracker/?func=detail&atid=106663&aid=3004656&group_id=6663

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100520124737.gb4...@cleo.wdw

Re: UPG and the default umask

[Santiago Vila]

On Thu, 20 May 2010, Raphael Hertzog wrote:

> Hi,
> 
> On Thu, 20 May 2010, Santiago Vila wrote:
> > So I agree that the sane thing to do here is, at least, to use the
> > same default range as /etc/adduser.conf (which in turn is the range
> > defined by policy).
> > 
> > I've just modified base-files accordingly to use the UID range 1000-2.
> 
> I'm not sure this makes lots of sense.
> 
> hert...@alioth:~$ id -u maximilinux-guest
> 220227
> 
> There are many installations out there with large numbers of users that
> simply can't respect the ranges set by the policy.
> 
> I would simply use a minimum of 500 or 1000 to differentiate system users
> from normal users. adduser is not a required step to create accounts when
> you manage your account database in LDAP/PostgreSQL (or whatever else).
> 
> Having a different behaviour betweent accounts simply because some are
> above the maximal limits and some are below would be counter productive.
> 
> The policy was written when uid/gid were only 16 bits but our systems cope
> with greater number of users nowadays... maybe the policy should be
> revised on that point.

Yes, maybe we should modify policy.

But for now, current policy says UIDs over 3 are "reserved", which means
they might or might not be "ordinary user accounts".

Those who do not use "adduser" because "they know that they are doing"
will surely be able to change /etc/profile if the default one is not
suitable for them, as it happens with every default value in the system.

If we don't follow policy closely here, we can't claim that the umask
change does only affect "ordinary user accounts" (which is what I
think the release notes for squeeze will say).

So, I'm just providing a default which is consistent with other
defaults in the system and also with policy.

If by doing so we realize as a result that policy should be modified,
let us modify policy then.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005201408240.21...@kolmogorov.unex.es

Re: UPG and the default umask

[Bastien ROUCARIES]

reopen 315089
thanks

On Mon, May 17, 2010 at 11:05 PM, Marvin Renich  wrote:
> * Aaron Toponce  [100517 13:05]:
>> On 05/17/2010 10:49 AM, Harald Braumann wrote:
>> > from pam_umask's description of the usergroups option:
>> >
>> > If the user is not root, and the user ID is equal to the group ID, *and*
>> > the username is the same as primary group name, the umask group bits
>> > are set to be the same as owner bits (examples: 022 -> 002, 077 ->
>> > 007).
>> >
>> > So if there is a mismatch of *either*, name or ID, then pam_umasks
>> > detects a non-UPG system, while it might very well be all UPG.
>>
>> A bug in pam_umask.so that needs to be addressed (which I believe we've
>> already started addressing in this thread).
>
> Bug #581984.

Closed by maintener and reopened, if we use libpam for umask it could
be even raised to RC critical, so please correct this behavior, report
upstream. I agree that it could be misleading for other distro in this
case, please add a newoption like useupg.

Thanks

Bastien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimvzj9octrxzidjc8kdzk6guhvedk5ssnrmo...@mail.gmail.com

Re: UPG and the default umask

[Peter Palfrader]

On Thu, 20 May 2010, Raphael Hertzog wrote:

> > So I agree that the sane thing to do here is, at least, to use the
> > same default range as /etc/adduser.conf (which in turn is the range
> > defined by policy).
> > 
> > I've just modified base-files accordingly to use the UID range 1000-2.
> 
> I'm not sure this makes lots of sense.
> 
> hert...@alioth:~$ id -u maximilinux-guest
> 220227
> 
> There are many installations out there with large numbers of users that
> simply can't respect the ranges set by the policy.
> 
> I would simply use a minimum of 500 or 1000 to differentiate system users
> from normal users. adduser is not a required step to create accounts when
> you manage your account database in LDAP/PostgreSQL (or whatever else).

System users can come out of ldap/NIS/etc too, and in such cases they
might not be in the 100-999 range either.

I fear anything which relies on ranges being used in some specific way
in deployed systems is fragile and prone to be wrong at least some of
the time.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100520121046.gs13...@anguilla.noreply.org

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Thu, 20 May 2010 00:22:02 +0200 (CEST), Santiago Vila 
wrote:
> If an admin which runs out of UIDs in his system modifies
> /etc/adduser.conf, will he remember to modify the upper bound in
> /etc/profile as well?
If these changes are going to be permanent and the discussion about them
has been aborted,... couldn't one grep the values out of adduser.conf?

Cheers,
Chris,


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13f7ebc613bb2965e22bf960669d2...@imap.dd24.net

Re: UPG and the default umask

[Raphael Hertzog]

Hi,

On Thu, 20 May 2010, Santiago Vila wrote:
> So I agree that the sane thing to do here is, at least, to use the
> same default range as /etc/adduser.conf (which in turn is the range
> defined by policy).
> 
> I've just modified base-files accordingly to use the UID range 1000-2.

I'm not sure this makes lots of sense.

hert...@alioth:~$ id -u maximilinux-guest
220227

There are many installations out there with large numbers of users that
simply can't respect the ranges set by the policy.

I would simply use a minimum of 500 or 1000 to differentiate system users
from normal users. adduser is not a required step to create accounts when
you manage your account database in LDAP/PostgreSQL (or whatever else).

Having a different behaviour betweent accounts simply because some are
above the maximal limits and some are below would be counter productive.

The policy was written when uid/gid were only 16 bits but our systems cope
with greater number of users nowadays... maybe the policy should be
revised on that point.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100520100849.gc8...@rivendell

Re: UPG and the default umask

[Santiago Vila]

On Thu, 20 May 2010, Roger Leigh wrote:

> On 19/05/2010 23:22, Santiago Vila wrote:
> > On Wed, 19 May 2010, Roger Leigh wrote:
> > 
> > > On 19/05/10 18:25, Santiago Vila wrote:
> > > > For the record: I've changed the umask setting in /etc/profile to this:
> > > > 
> > > > if [ "`id -u`" -ge 1000 ]; then
> > > 
> > > Should we also be catering for the reserved globally allocated UIDs in the
> > > range 6-64999 with this check (Policy §9.2.2)?
> > 
> > Hmm, good question. Can you give me an example of an uid which has
> > been allocated that way?
> 
> I'm not aware of any, TBH.  It's just a case where future use might cause
> potential vulnerabilities if not catered for as for UIDs <1000 since you'd be
> using 0002 where 0022 would be expected.
> 
> > Perhaps I should follow policy more closely, yes, but that would mean
> > using the range 1000-2 only, not 1000-5, as 3-5 is
> > "reserved" (whatever that means).
> > 
> > If an admin which runs out of UIDs in his system modifies
> > /etc/adduser.conf, will he remember to modify the upper bound in
> > /etc/profile as well?
> 
> Maybe the above check should source /etc/adduser.conf and use the values
> LAST_SYSTEM_UID and LAST_UID (or default to 0022 and then enable and 0002
> umask if in the range FIRST_UID to LAST_UID which is a bit simpler):
> 
> UMASK=0022
> # In a UPG setup, relax umask to 0002.
> if [ "$(id -u)" -ge "$FIRST_UID" -a "$(id -u)" -le "$LAST_UID" ]; then
>   UMASK=0002
> fi
> umask "$UMASK"

That would be much nicer, yes, but adduser is priority important and
base-files is required and essential, so that would not work if
adduser is removed, unless we make the code more complex again,
which I'm trying to avoid.

When adduser goes out of UIDs, this is what happens:

Adding user `somebody' ...
adduser: No UID/GID pair is available in the range 1000-1000 (FIRST_UID - 
LAST_UID).
adduser: The user `somebody' was not created.

So I agree that the sane thing to do here is, at least, to use the
same default range as /etc/adduser.conf (which in turn is the range
defined by policy).

I've just modified base-files accordingly to use the UID range 1000-2.

Thanks a lot for the input.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005201121130.18...@kolmogorov.unex.es

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 03:48 PM, Christoph Anton Mitterer wrote:
> See above, or do you wish a larger paper discussing the issues?! ^^

So FUD it is. At least you're consistent.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Charles Plessy]

Le Wed, May 19, 2010 at 01:10:25PM -0600, Aaron Toponce a écrit :
> 
> UPG is only if the user name and group name match,
> and the user is the only member of that group.

Hi Aaron and everybody,

is there any ‘official’ definition of UPG, for instance the first document
presenting the concept after it was finalised? I was looking for such a
reference for the patch to the release notes but could not find one.

By the way, for following the corrections of the Debian documentations as well
as the bugs found by changing the umask, I suggest to use the following wiki
page: http://wiki.debian.org/umask

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100519235440.gb13...@kunpuu.plessy.org

Re: UPG and the default umask

[Roger Leigh]

On 19/05/2010 23:22, Santiago Vila wrote:

On Wed, 19 May 2010, Roger Leigh wrote:


On 19/05/10 18:25, Santiago Vila wrote:

For the record: I've changed the umask setting in /etc/profile to this:

if [ "`id -u`" -ge 1000 ]; then


Should we also be catering for the reserved globally allocated UIDs in the
range 6-64999 with this check (Policy §9.2.2)?


Hmm, good question. Can you give me an example of an uid which has
been allocated that way?


I'm not aware of any, TBH.  It's just a case where future use might 
cause potential vulnerabilities if not catered for as for UIDs <1000 
since you'd be using 0002 where 0022 would be expected.



Perhaps I should follow policy more closely, yes, but that would mean
using the range 1000-2 only, not 1000-5, as 3-5 is
"reserved" (whatever that means).

If an admin which runs out of UIDs in his system modifies
/etc/adduser.conf, will he remember to modify the upper bound in
/etc/profile as well?


Maybe the above check should source /etc/adduser.conf and use the values 
LAST_SYSTEM_UID and LAST_UID (or default to 0022 and then enable and 
0002 umask if in the range FIRST_UID to LAST_UID which is a bit simpler):


UMASK=0022
# In a UPG setup, relax umask to 0002.
if [ "$(id -u)" -ge "$FIRST_UID" -a "$(id -u)" -le "$LAST_UID" ]; then
  UMASK=0002
fi
umask "$UMASK"


Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf472b4.5090...@codelibre.net

Re: UPG and the default umask

[Stanislav Maslovski]

On Mon, May 17, 2010 at 04:00:57AM +0200, Thomas Hochstein wrote:
> Felipe Sateler schrieb:
> 
> > 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.

I think that in a UPG environment you could achieve the same (at least
in the case when there is a certain directory in which all those users
create their files, like /var/www/ or something) with a combination of
a common group, umask 072, and a setgid bit (and most likely a sticky
bit too to prevent deletions) on the shared directory.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100519232410.ga32...@kaiba.homelan

Re: UPG and the default umask

[Stefano Zacchiroli]

On Wed, May 19, 2010 at 09:11:54PM +, Christoph Anton Mitterer wrote:
> Nevertheless may I suggest to stop any further active changes in that
> issue (UPG/umask) until this discussion here is over and final
> decision has been made.

Sorry, but Debian is a do-ocracy first, and a democracy then. AFAICT you
do not maintain any of the involved packages, so thus far your best
attempt has been to convince the maintainer of your ideas, which is a
reasonable course of action.

As of now, you've posted 30 messages in 4 days, arguably often repeating
the same arguments; apparently, you did not manage to convince the
maintainer to change his decision. If I were at your place, I would have
realized by now that continuing along this pattern won't achieve much
more.

Now, I'm deeply sorry you got insults in private mail, that's surely not
appropriate.

In spite of that, from here you have the following choices: (1) engage
the democracy part of Debian in an attempt to overrule the maintainer
decision (note that you would need some DDs to support that course of
action), (2) give up (possibly changing your distribution of choice due
to this change, which would make me sad), (3) continue your previous
pattern.

Among these choices, I gently ask you not to pursue the latter.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Santiago Vila]

On Wed, 19 May 2010, Roger Leigh wrote:

> On 19/05/10 18:25, Santiago Vila wrote:
> > For the record: I've changed the umask setting in /etc/profile to this:
> > 
> > if [ "`id -u`" -ge 1000 ]; then
> 
> Should we also be catering for the reserved globally allocated UIDs in the
> range 6-64999 with this check (Policy §9.2.2)?

Hmm, good question. Can you give me an example of an uid which has
been allocated that way?

Perhaps I should follow policy more closely, yes, but that would mean
using the range 1000-2 only, not 1000-5, as 3-5 is
"reserved" (whatever that means).

If an admin which runs out of UIDs in his system modifies
/etc/adduser.conf, will he remember to modify the upper bound in
/etc/profile as well?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.100526430.8...@kolmogorov.unex.es

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce

wrote:
> You've only mentioned that SSH won't operate if the write bit is set on
> the keys or anything under the ~/.ssh/ directory. Can you explain how an
> ssh client failing to connect to an external ssh server because of the
> umask is compromising security on the system?

Simply read the mails and those from the other critics again, it's not
only annoying for myself to repeat things over and over again but also for
everybody else to read it again.
Nevertheless just saying "everything's fine" or "you only complained about
ssh" won't really solve the issues, but just help to wave these changes
through.


> Also, can you please provide an extra carriage return between your reply
> and the quoted text? Reading your replies is a bit annoying.

Any other wishes to please your MUA? Different character encoding? MIME?


> Please explain how people's security is compromised because their umask
> is 0002 instead of 0022. I'm still waiting for this FUD to be backed up.

See above, or do you wish a larger paper discussing the issues?! ^^


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7f276af2e79987201aa98eaecb317...@imap.dd24.net

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 03:11 PM, Christoph Anton Mitterer wrote:
> Or is that already, the case? At least I've had the impression that
> neither mine, nor the arguments of some other people (Harald, Peter, etc.)
> were even answered here.

You've only mentioned that SSH won't operate if the write bit is set on
the keys or anything under the ~/.ssh/ directory. Can you explain how an
ssh client failing to connect to an external ssh server because of the
umask is compromising security on the system?

Also, can you please provide an extra carriage return between your reply
and the quoted text? Reading your replies is a bit annoying.

> The reason could be that people simply don't recognise, that they might
> have compromised their own security... and those who know what happens
> don't complain.

Please explain how people's security is compromised because their umask
is 0002 instead of 0022. I'm still waiting for this FUD to be backed up.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Christoph Anton Mitterer]

btw: What happened to the idea of movin umask completely away from
/etc/profile?
I mean regardless of the discussion about UPGs and which value is the
"best" default for umask, I found it to be a good idea to drop it there.

Can someone please explain me the reason why login.defs isn't used for
that?


Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/08ab89016e3f8352697e1a4700582...@imap.dd24.net

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Wed, 19 May 2010 22:51:25 +0200, Willi Mann  wrote:
> The gain would be a guard against accidental 002 umasks in non-UPG 
> environments, which I'm quite sure will happen. Either because admins do
> not 
> read the release notes or because they forget to do the change on one of

> their newly-installed machines despite reading the release notes. 
I also think, that the current check is far to less...


Nevertheless may I suggest to stop any further active changes in that
issue (UPG/umask) until this discussion here is over and final decision has
been made.
Or is that already, the case? At least I've had the impression that
neither mine, nor the arguments of some other people (Harald, Peter, etc.)
were even answered here.


> On the other hand, other distributions already use default 002 umask 
> unconditionally and I'm not aware of any complaints. So admins in
non-UPG 
> environments using these distros seem to be able to cope with it. 
The reason could be that people simply don't recognise, that they might
have compromised their own security... and those who know what happens
don't complain.


> However, there might be stronger expectations about Debian's default 
> security-related settings,
Well... I guess you can forget about that.


> which might explain the harsh wordings chosen
> by 
> some opponents of this change.
Funny that you notice it I was (off list) mailed by some people and
harshly insulted with words I better don't repeat here,... and not even for
technical reasons, as stated, but just because I don't bow to what is
considered the majority.


And from all of us here: I wish you happy painting,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/39a6ceb8f92bb5718dc558d118c57...@imap.dd24.net

Re: UPG and the default umask

[Willi Mann]

Hi!

> Some people proposed complex code to determine whether UPG was in use
> for system users. Such thing would be an "exception to the exception"
> and as such I think it would be a bad thing, as it would make things
> a lot more complex without any real gain.

The gain would be a guard against accidental 002 umasks in non-UPG 
environments, which I'm quite sure will happen. Either because admins do not 
read the release notes or because they forget to do the change on one of 
their newly-installed machines despite reading the release notes. 

On the other hand, other distributions already use default 002 umask 
unconditionally and I'm not aware of any complaints. So admins in non-UPG 
environments using these distros seem to be able to cope with it. 

However, there might be stronger expectations about Debian's default 
security-related settings, which might explain the harsh wordings chosen by 
some opponents of this change.

WM


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ht1j0f$m8...@dough.gmane.org

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 01:25 PM, James Vega wrote:
> Except /etc/profile won't be sourced again unless "newgrp - " is
> used, right?

Correct, or the user issues a new login shell after the change has been
made.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 01:20 PM, Philipp Kern wrote:
> Sorry, I assumed that UPG is a system-wide concept and that I could just
> change to my collaboration group and have a useful umask there too.  So we
> only cater for the setgid flag on directories?

The "newgrp" command changes your default group. The default group is
what is applied to files when you create them. So, if you change your
default group to a collaborative group, then realize that they will have
access to those files you create outside of the collaboration directory.

The better way to approach this, would be to just append the
collaborative group to the user, but keep his private group as his
default group.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[James Vega]

On Wed, May 19, 2010 at 3:10 PM, Aaron Toponce  wrote:
> On 05/19/2010 01:00 PM, Philipp Kern wrote:
>> When I do "newgrp " it's still UPG and the umask should still be
>> 2, no?  This check would change my umask.
>
> If the new default group is named something other than your username,
> it's no longe UPG. UPG is only if the user name and group name match,
> and the user is the only member of that group.
>
> So, to answer your question, if your username was "foo" and you belonged
> to group "foo", of which you are the only member, then you do a "newgrp
> bar" for foo, foo is no longer in a UPG situation, so his umask should
> be 0022 at that point.

Except /etc/profile won't be sourced again unless "newgrp - " is
used, right?

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimillfzkvbwdk2ruzmldg88pjmjtvhskvuyl...@mail.gmail.com

Re: UPG and the default umask

[Philipp Kern]

On 2010-05-19, Aaron Toponce  wrote:
> On 05/19/2010 01:00 PM, Philipp Kern wrote:
>> When I do "newgrp " it's still UPG and the umask should still be=
>> 2, no?  This check would change my umask.
>
> If the new default group is named something other than your username,
> it's no longe UPG. UPG is only if the user name and group name match,
> and the user is the only member of that group.

Sorry, I assumed that UPG is a system-wide concept and that I could just
change to my collaboration group and have a useful umask there too.  So we
only cater for the setgid flag on directories?

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhv8efm.l1r.tr...@kelgar.0x539.de

Re: UPG and the default umask

[Roger Leigh]

On 19/05/10 18:25, Santiago Vila wrote:

For the record: I've changed the umask setting in /etc/profile to this:

if [ "`id -u`" -ge 1000 ]; then


Should we also be catering for the reserved globally allocated UIDs in 
the range 6-64999 with this check (Policy §9.2.2)?


Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf437f2.2090...@codelibre.net

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 01:00 PM, Philipp Kern wrote:
> When I do "newgrp " it's still UPG and the umask should still be
> 2, no?  This check would change my umask.

If the new default group is named something other than your username,
it's no longe UPG. UPG is only if the user name and group name match,
and the user is the only member of that group.

So, to answer your question, if your username was "foo" and you belonged
to group "foo", of which you are the only member, then you do a "newgrp
bar" for foo, foo is no longer in a UPG situation, so his umask should
be 0022 at that point.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Philipp Kern]

On 2010-05-19, Aaron Toponce  wrote:
> I suggested this, which I don't think is complex. However, what you have
> suggested should work just fine.
>
> if [ "$(id -un)" =3D "$(id -gn)" ] && [ "$UID" -gt 99 ]; then
> umask 0002
> else
> umask 0022
> fi

id -n might cause network accesses, if NSS is configured to do so.  Is there
a precedent in profile for this?  (I don't see any, just id -u which calls
getuid.)

> The logic is simple, IMO: if the group name and the user name match,
> it's UPG. If UPG and it is not a system user, then set the umask to
> 0002. Otherwise, set to 0022.

When I do "newgrp " it's still UPG and the umask should still be
2, no?  This check would change my umask.

> I don't know if that logic will match any additional cases (unless user
> accounts are created under ID 1000), however, so we should be good with
> your simpler logic on just matching the UID.

Right.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhv8da1.kea.tr...@kelgar.0x539.de

Re: UPG and the default umask

[Aaron Toponce]

On 05/19/2010 11:25 AM, Santiago Vila wrote:
> For the record: I've changed the umask setting in /etc/profile to this:
> 
> if [ "`id -u`" -ge 1000 ]; then
>   umask 002
> else
>   umask 022
> fi

[snip]

> Some people proposed complex code to determine whether UPG was in use
> for system users. Such thing would be an "exception to the exception"
> and as such I think it would be a bad thing, as it would make things
> a lot more complex without any real gain.

I suggested this, which I don't think is complex. However, what you have
suggested should work just fine.

if [ "$(id -un)" = "$(id -gn)" ] && [ "$UID" -gt 99 ]; then
umask 0002
else
umask 0022
fi

The logic is simple, IMO: if the group name and the user name match,
it's UPG. If UPG and it is not a system user, then set the umask to
0002. Otherwise, set to 0022.

I don't know if that logic will match any additional cases (unless user
accounts are created under ID 1000), however, so we should be good with
your simpler logic on just matching the UID.

Speaking of which, because of NFS, should matching just the UID -ge 1000
a good idea? Other systems start their accounts at 500, and matching UID
is critical in NFS environments. Just a thought.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Santiago Vila]

For the record: I've changed the umask setting in /etc/profile to this:

if [ "`id -u`" -ge 1000 ]; then
  umask 002
else
  umask 022
fi

which is fully consistent with Debian policy when it says that user
accounts, by default, start at uid 1000.

So, this is now a very simple rule (umask 002) with a very simple
exception (not an user account), and I'm now confortable enough with
it to not ask it to be moved elsewhere (PAM or login.defs).

Some people proposed complex code to determine whether UPG was in use
for system users. Such thing would be an "exception to the exception"
and as such I think it would be a bad thing, as it would make things
a lot more complex without any real gain.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005191903510.17...@cantor.unex.es

Re: UPG and the default umask

[Roger Lynn]

On 18/05/10 11:00, Christoph Anton Mitterer wrote:
> Not to speak about, that UPG is anyway a questionable abuse of the
> user/group concept.
> 
> Neither to speak about the fact, that in the 17 years debian exists
> now,... no majority missed that "feature" (apparently).

Debian has been using UPG for decades yet no one has complained about
it. Why didn't you raise a bug when UPG was first introduced?

People configuring Debian to run in a non-UPG environment can quite
easily also change the umask. As Debian uses UPG by default then the
default umask should be 0002. If you change one then you can change the
other at the same time.

Roger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf2ff5c.1070...@rilynn.me.uk

Re: UPG and the default umask

[Harald Braumann]

If you want to answer, please do it on the list. I'm not interested in
a private discussion.

On Tue, May 18, 2010 at 04:23:24PM +0200, Bernhard R. Link wrote:
> * Harald Braumann  [100518 16:16]:
> > There is already an upstream bug [0], but even if it get's
> > implemented, that wouldn't magically change all systems out there
> > running non-UPG
> 
> We are not talking about system running non-UPG here. Were are talking
> about newly installed systems, thus UPG systems.

There seems to be a widespread misconception, that there is only ever
one isolated machine that does local user management. I think it is
quite common in a network, to have users in LDAP or some other central
database. If I install a machine in such an environment, it has to
take whatever LDAP provides. I'm not going to change the whole user
management, just for a newly installed Debian machine. 

> > A umask of 022 is the right choice for most people and at least
> > doesn't put the others at risk.
> 
> Please do not troll.

I can not but yield to your conclusive argumentation and will from now
on be quiet on this matter. In any case, I think I have presented all
my arguments.

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100518193406.gc4...@sbs288.lan

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Tue, 2010-05-18 at 17:38 +0200, Hendrik Sattler wrote:
> Do  e.g. backup system deal well with ACLs?
Definitely not all,... but I guess those should be fixed anyway (totally
regardless of UPGs/umask issues)...


> The standard tar doesn't, except 
> when you script around it... or if you use star.
I think you're right for GNU's upstream sources,... but if I remember
correctly, Fedora and RHEL ship patches, which enable support for ACLs,
xattrs, and SELinux.

Will file a wishlist bug against Debian's tar when I find them :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: UPG and the default umask

[Andrei Popescu]

On Tue,18.May.10, 16:16:06, Harald Braumann wrote:
 
> A umask of 022 is the right choice for most people and at least
> doesn't put the others at risk. Everyone, who knows what a setgid
> directory is and how it works, will also know, that there are certain
> requirements on the umask. And the others really don't care, as long
> as their security is not compromised.

Except for the other group of "others", who have no idea what setgid is, 
don't care too much about security and just wonder why it is so 
difficult to share files with another user on the same machine.

But it doesn't matter, they'll just go back to Windows anyway.  
It's better suited for home users anyway.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Hendrik Sattler]

Am Dienstag 18 Mai 2010, 12:49:08 schrieb Christoph Anton Mitterer:
> > If you are not allowed to use ACLs
> 
> That's no reason for UPGs to exist, is it?
> All important filesystems support ACLs, right? All kernels in Debian and
> do so, right? So technically, no problem.
> So being "not allowed" probably means organisational issues, right? But
> then talk to your admins.
> 
> What's done here is to abuse a system just to workaround something else
> ("don't have/want to ACLs), right?

Do  e.g. backup system deal well with ACLs? The standard tar doesn't, except 
when you script around it... or if you use star.

HS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005181738.07833.p...@hendrik-sattler.de

Re: UPG and the default umask

[Harald Braumann]

On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote:
> On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
> > On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
> >> On 2010-05-18, Christoph Anton Mitterer  wrote:
> >> > Not to speak about, that UPG is anyway a questionable abuse of the
> >> > user/group concept.
> >> >
> >> > Neither to speak about the fact, that in the 17 years debian exists
> >> > now,... no majority missed that "feature" (apparently).
> >>
> >> So you present that as universal facts as if you've booked the truth
> >> (possibly a bad translation of a German saying).
> >>
> >> I think that feature is useful for all those who don't want to mess
> >> with ACLs.  If you are not allowed to use ACLs and don't have UPG
> >> with sane umasks collaboration is painful (see e.g. Debian infrastrure
> >> with all users being in group Debian and default umask 0022 which
> >> leads to wrong permissions in setgid directories, with ACLs being
> >> disallowed).  So indeed I got a script which does newgrp and
> >> setting the umask for me which I run whenever I want to do release
> >> tasks.  But it would be more sane if the user wouldn't have to
> >> care about that.
> >
> > Let me quote from the comments in /etc/login.defs:
> >
> > # 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.
> >
> > And that's exactly the problem: there is no one-size-fits-all
> > for the umask. Yes, for collaboration in a setgid directory you'd have
> > to use 002 and thanks to UPG this is possible without compromising
> > security. But I consider this just a special case. There are
> > cases where Debian runs in a non-UPG environment, where you can't use
> > that umask. And I don't think that's uncommon. Think of a mixed
> > environment with Windows, where you might have a samba domain in LDAP. And
> > last time I checked, the smbldap-tools didn't support UPG.
> 
> Could you fill a bug report against smbldap-tools ?

There is already an upstream bug [0], but even if it get's
implemented, that wouldn't magically change all systems out there
running non-UPG

> 
> 
> > So whatever value is used as the default, half of the users will have
> > to change it anyway, to fit their needs. And in such a case, where
> > there is no single optimal value, I'd rather have the most
> > conservative as default.
> >
> > If the umask is 022 and you create a setgid
> > directory and forget to change the umask, you will quickly realise
> > that things are not working as expected and fix it. If the umask is
> > 002 and you add your Debian system to a non-UPG environment and forget
> > to change the umask, things will still work perfectly but you put all
> > your files at risk and might not even realise it until it is too
> > late.
> 
> Why not add a security dialog and assistant for installing and
> upgrading the system?
> It will ease the transition and fit allt the need, documenting
> drawbacks and advantages of each scheme ?

A umask of 022 is the right choice for most people and at least
doesn't put the others at risk. Everyone, who knows what a setgid
directory is and how it works, will also know, that there are certain
requirements on the umask. And the others really don't care, as long
as their security is not compromised.

There is really no need to force everyone to make a useless decision,
just for the sake of a change to make life of a specific minority easier.

Cheers,
harry

[0] http://gna.org/support/?2040


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100518141606.gb4...@sbs288.lan

Re: UPG and the default umask

[Bastien ROUCARIES]

On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
> On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
>> On 2010-05-18, Christoph Anton Mitterer  wrote:
>> > Not to speak about, that UPG is anyway a questionable abuse of the
>> > user/group concept.
>> >
>> > Neither to speak about the fact, that in the 17 years debian exists
>> > now,... no majority missed that "feature" (apparently).
>>
>> So you present that as universal facts as if you've booked the truth
>> (possibly a bad translation of a German saying).
>>
>> I think that feature is useful for all those who don't want to mess
>> with ACLs.  If you are not allowed to use ACLs and don't have UPG
>> with sane umasks collaboration is painful (see e.g. Debian infrastrure
>> with all users being in group Debian and default umask 0022 which
>> leads to wrong permissions in setgid directories, with ACLs being
>> disallowed).  So indeed I got a script which does newgrp and
>> setting the umask for me which I run whenever I want to do release
>> tasks.  But it would be more sane if the user wouldn't have to
>> care about that.
>
> Let me quote from the comments in /etc/login.defs:
>
> # 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.
>
> And that's exactly the problem: there is no one-size-fits-all
> for the umask. Yes, for collaboration in a setgid directory you'd have
> to use 002 and thanks to UPG this is possible without compromising
> security. But I consider this just a special case. There are
> cases where Debian runs in a non-UPG environment, where you can't use
> that umask. And I don't think that's uncommon. Think of a mixed
> environment with Windows, where you might have a samba domain in LDAP. And
> last time I checked, the smbldap-tools didn't support UPG.

Could you fill a bug report against smbldap-tools ?


> So whatever value is used as the default, half of the users will have
> to change it anyway, to fit their needs. And in such a case, where
> there is no single optimal value, I'd rather have the most
> conservative as default.
>
> If the umask is 022 and you create a setgid
> directory and forget to change the umask, you will quickly realise
> that things are not working as expected and fix it. If the umask is
> 002 and you add your Debian system to a non-UPG environment and forget
> to change the umask, things will still work perfectly but you put all
> your files at risk and might not even realise it until it is too
> late.

Why not add a security dialog and assistant for installing and
upgrading the system?
It will ease the transition and fit allt the need, documenting
drawbacks and advantages of each scheme ?

And offer a sensible default choice (and skip button) for desktop user ?

Regards

Bastien

> Cheers,
> harry
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin92rw-krk1jajy6knyqm6z-mzt4hd8wzchf...@mail.gmail.com

Re: UPG and the default umask

[Philipp Kern]

On 2010-05-18, Harald Braumann  wrote:
> If the umask is 022 and you create a setgid
> directory and forget to change the umask, you will quickly realise
> that things are not working as expected and fix it. If the umask is
> 002 and you add your Debian system to a non-UPG environment and forget
> to change the umask, things will still work perfectly but you put all
> your files at risk and might not even realise it until it is too
> late.

I guess we need a Debian Administration Best Practises Guide.  There are
many stupid things you can do while being root, with things still working
perfectly.

But then somebody would need to take care of the document (i.e. a
continuations of the release notes for future generations).

Kind regards,
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhv568l.91l.tr...@kelgar.0x539.de

Re: UPG and the default umask

[Harald Braumann]

On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
> On 2010-05-18, Christoph Anton Mitterer  wrote:
> > Not to speak about, that UPG is anyway a questionable abuse of the
> > user/group concept.
> >
> > Neither to speak about the fact, that in the 17 years debian exists
> > now,... no majority missed that "feature" (apparently).
> 
> So you present that as universal facts as if you've booked the truth
> (possibly a bad translation of a German saying).
> 
> I think that feature is useful for all those who don't want to mess
> with ACLs.  If you are not allowed to use ACLs and don't have UPG
> with sane umasks collaboration is painful (see e.g. Debian infrastrure
> with all users being in group Debian and default umask 0022 which
> leads to wrong permissions in setgid directories, with ACLs being
> disallowed).  So indeed I got a script which does newgrp and
> setting the umask for me which I run whenever I want to do release
> tasks.  But it would be more sane if the user wouldn't have to
> care about that.

Let me quote from the comments in /etc/login.defs:

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

And that's exactly the problem: there is no one-size-fits-all
for the umask. Yes, for collaboration in a setgid directory you'd have
to use 002 and thanks to UPG this is possible without compromising
security. But I consider this just a special case. There are
cases where Debian runs in a non-UPG environment, where you can't use
that umask. And I don't think that's uncommon. Think of a mixed
environment with Windows, where you might have a samba domain in LDAP. And
last time I checked, the smbldap-tools didn't support UPG.

So whatever value is used as the default, half of the users will have
to change it anyway, to fit their needs. And in such a case, where
there is no single optimal value, I'd rather have the most
conservative as default. 

If the umask is 022 and you create a setgid
directory and forget to change the umask, you will quickly realise
that things are not working as expected and fix it. If the umask is
002 and you add your Debian system to a non-UPG environment and forget
to change the umask, things will still work perfectly but you put all
your files at risk and might not even realise it until it is too
late.

Cheers,
harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100518131240.ga4...@sbs288.lan

Re: UPG and the default umask

[Michael Banck]

On Tue, May 18, 2010 at 02:13:46PM +0200, Michael Banck wrote:
> On Tue, May 18, 2010 at 10:49:08AM +, Christoph Anton Mitterer wrote:
> > On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern 
> > wrote:
> > > So you present that as universal facts as if you've booked the truth
> > > (possibly a bad translation of a German saying).
> > No,.. and normally I would simply shut up, as I'm not even DD... but this
> > here breaks simply so much which I believe in and contradicts so many
> > proven paradigms, that I prefer to raise up even if that means, that I
> > don't make any friends here.
> 
> It's not speaking up which is the problem, it's the Sven-Luther style of
> argumentation.

What I meant is that you seem to very passionate about this topic, and
reply to a lot of messages with similar content in short succession,
while it might be better to first see what arguments others come up with
and address new ones as you see fit.


Thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100518122443.gg3...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Michael Banck]

On Tue, May 18, 2010 at 11:34:47AM +, Christoph Anton Mitterer wrote:
> is there a list of distros that have UPGs fully deployed?

This is not Q&A list, you are allowed to do research yourself and
present it here.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100518121505.gf3...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Michael Banck]

On Tue, May 18, 2010 at 10:49:08AM +, Christoph Anton Mitterer wrote:
> On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern 
> wrote:
> > So you present that as universal facts as if you've booked the truth
> > (possibly a bad translation of a German saying).
> No,.. and normally I would simply shut up, as I'm not even DD... but this
> here breaks simply so much which I believe in and contradicts so many
> proven paradigms, that I prefer to raise up even if that means, that I
> don't make any friends here.

It's not speaking up which is the problem, it's the Sven-Luther style of
argumentation.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100518121346.ge3...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Tue, 18 May 2010 12:32:56 +0200, Christian PERRIER 
wrote:
> evolutions that are apparently an evidence for all
> other distros.
Apart from whether everything what other do or do not is automatically an
evolutions (e.g. dotnet/mono)...

is there a list of distros that have UPGs fully deployed?


Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/297e37bdea3d58d08f1f1d529a15d...@imap.dd24.net

Re: UPG and the default umask

[Christian PERRIER]

Quoting Christoph Anton Mitterer (cales...@scientia.net):

> Neither to speak about the fact, that in the 17 years debian exists
> now,... no majority missed that "feature" (apparently).

I bet this will improve over time, until the day nobody is using
Debian anymore (hence nobody missing the feature, too) if we always
refuse to adopt evolutions that are apparently an evidence for all
other distros.

In case someone would wonde, yes, that was sarcastic mode I wonder
whether I'm really only half-kidding, however, or if that joke could
become true in some future.






signature.asc
Description: Digital signature

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern 
wrote:
> So you present that as universal facts as if you've booked the truth
> (possibly a bad translation of a German saying).
No,.. and normally I would simply shut up, as I'm not even DD... but this
here breaks simply so much which I believe in and contradicts so many
proven paradigms, that I prefer to raise up even if that means, that I
don't make any friends here.

 
> I think that feature is useful for all those who don't want to mess
> with ACLs.
Well I guess this already hints to it:
- groups, were intended to group different users together and not to rely
that only one users is in its own group (which is as far as I understood
what UPGs do, right?)
- If one wants more (collaboration stuff and that on): We have ACLs, which
are just intended for all that,... allowing finer grained access rules. And
I guess many collaborative issues are dealt with at a much higher level
than the fs anyway...

> If you are not allowed to use ACLs
That's no reason for UPGs to exist, is it?
All important filesystems support ACLs, right? All kernels in Debian and
do so, right? So technically, no problem.
So being "not allowed" probably means organisational issues, right? But
then talk to your admins.

What's done here is to abuse a system just to workaround something else
("don't have/want to ACLs), right?


> and don't have UPG
> with sane umasks collaboration is painful (see e.g. Debian infrastrure
> with all users being in group Debian and default umask 0022 which
> leads to wrong permissions in setgid directories,
> with ACLs being
> disallowed).
Was there any special reason for this?

> So indeed I got a script which does newgrp and
> setting the umask for me which I run whenever I want to do release
> tasks.  But it would be more sane if the user wouldn't have to
> care about that.

- Even if I'd see a technical use case/benefit (that could not be gained
via other means that are intended for this),... I wouldn't do this as
default.

- There are probably many unpredictable side effects (see what Peter has
noted) and the need to hack around stuff which is perfectly ok as it is (I
guess this is going to be done e.g. in ssh).

And - for me most important - it shows some evil trends:
- We more or less start forcing users to go a special way (in this case
"using UPGs").
I know you'll say that everybody can simply go back, but if this like
changing unrelated packages go on, the day will come sooner than later
where this is not easily possible.
- We start sacrifice security.


Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1504291ecb28d8c42cad3ab73ad80...@imap.dd24.net

Re: UPG and the default umask

[Petter Reinholdtsen]

[Christoph Anton Mitterer]
> Neither to speak about the fact, that in the 17 years debian exists
> now,... no majority missed that "feature" (apparently).

Well, a minority in Debian Edu have missed it since the Debian Edu
project started integrating our configuration into Debian, and are
very happy with the fact that UPG finally will work out of the box in
Debian. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2flmxvxcxqm@login1.uio.no

Re: UPG and the default umask

[Philipp Kern]

On 2010-05-18, Christoph Anton Mitterer  wrote:
> Not to speak about, that UPG is anyway a questionable abuse of the
> user/group concept.
>
> Neither to speak about the fact, that in the 17 years debian exists
> now,... no majority missed that "feature" (apparently).

So you present that as universal facts as if you've booked the truth
(possibly a bad translation of a German saying).

I think that feature is useful for all those who don't want to mess
with ACLs.  If you are not allowed to use ACLs and don't have UPG
with sane umasks collaboration is painful (see e.g. Debian infrastrure
with all users being in group Debian and default umask 0022 which
leads to wrong permissions in setgid directories, with ACLs being
disallowed).  So indeed I got a script which does newgrp and
setting the umask for me which I run whenever I want to do release
tasks.  But it would be more sane if the user wouldn't have to
care about that.

(In other environments default ACLs solve this problem in some way
or another, if you throw another periodic cronjob onto the problem
which deal with the few exceptions created by e.g. mv.)

Kind regards,
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhv4poh.6us.tr...@kelgar.0x539.de

Re: UPG and the default umask

[Christoph Anton Mitterer]

Hi Peter.

On Tue, 18 May 2010 09:48:15 +0200, Peter Palfrader 
wrote:
> Anyway, my point remains:  Procedures that were perfectly fine and
> secure up until now would suddenly be broken and dangerous.
I guess you're wasting your time... the many arguments which either showed
concrete technical (security) problems (e.g. your tar issue here or the
ugly need to patch stuff like ssh) as well as more general (security)
concepts which speaks against those changes (and although I'm in minority,
I was not the only one with strong concerns) are simply ignored.

Not to speak about, that UPG is anyway a questionable abuse of the
user/group concept.

Neither to speak about the fact, that in the 17 years debian exists
now,... no majority missed that "feature" (apparently).

Best wishes,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/d25e0d5acb17eaa35b79d8519fe5b...@imap.dd24.net

Re: UPG and the default umask

[Bernhard R. Link]

* Peter Palfrader  [100518 09:48]:
> Not exactly true.  Untarring as root preserves these things by default.

Tar also preserves users. As one user name (or id) might be trusted on
one system, but be an other person on an other system, that is already
dangerous.

> Also, using rsync with -avz is pretty standard.

That already preserves the group names if possible. So it means that if
you are in a group with the same name on two computers but with
different meaning you can give permissions to people you have not
intended. So rsync -a is already dangerous in the way you describe.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100518093631.ga18...@pcpool00.mathematik.uni-freiburg.de

Re: UPG and the default umask

[Peter Palfrader]

On Mon, 17 May 2010, Bernhard R. Link wrote:

> * Peter Palfrader  [100517 16:41]:
> > 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.

Not exactly true.  Untarring as root preserves these things by default.
Also, using rsync with -avz is pretty standard.

Anyway, my point remains:  Procedures that were perfectly fine and
secure up until now would suddenly be broken and dangerous.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100518074815.gi8...@anguilla.noreply.org

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 3:34 PM, Marvin Renich  wrote:
> * Reinhard Tartler  [100517 08:56]:
>> 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));
>> |         }
>> |         }
>> |     }
>> `

Another bug is the code does not check if they are only one user on the group.

Regards

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktiljeb7l0vnlvyz-q3kij4fvrmxldjpkkz6v3...@mail.gmail.com

Re: UPG and the default umask

[Marvin Renich]

* Aaron Toponce  [100517 13:05]:
> On 05/17/2010 10:49 AM, Harald Braumann wrote:
> > from pam_umask's description of the usergroups option:
> > 
> > If the user is not root, and the user ID is equal to the group ID, *and*
> > the username is the same as primary group name, the umask group bits
> > are set to be the same as owner bits (examples: 022 -> 002, 077 ->
> > 007). 
> > 
> > So if there is a mismatch of *either*, name or ID, then pam_umasks
> > detects a non-UPG system, while it might very well be all UPG.
> 
> A bug in pam_umask.so that needs to be addressed (which I believe we've
> already started addressing in this thread).

Bug #581984.

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

Then you must have manually configured the system, and you need to
manually configure PAM or /etc/profile or whatever to address all the
issues of your deviation from _defaults_.

Out of the box, Debian (we are not discussing other distros) uses UPG
and always uses the username for the name of the UPG assigned to that
user, unless you manually select a different group name, at which point
we are back to the point about an admin who deviates from defaults needs
to be aware of the consequences.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517210507.gj1...@cleo.wdw

Re: UPG and the default umask

[Tollef Fog Heen]

]] Christoph Anton Mitterer 

| On Mon, 2010-05-17 at 11:50 -0600, Aaron Toponce wrote:
| > How does this compromise security when you're the only member of your
| > private group?
| And if you are not?

Then you have a misconfigured system where security might be
compromised.  If it's intentional, you should also change the system
umask, be it using pam_umask, /etc/profile or whatever mechanism you
wish.

| Why should you? Well someone simply might not want to use UPG? Or might
| use the users or staff group?
| 
| Or do "we" now basically force everybody to use UPG?

See above, you then have to configure the system to not use UPGs.

| >  seeing as though Debian is a UPG-based operating system.

| Is it? Again,... speechless...

Yes, out of the box, each user has their private group and the umask is
0002, making it a UPG-based system.  That does not mean you can't
configure it otherwise of course.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq6m5kl1@qurzaw.linpro.no

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Mon, 2010-05-17 at 11:50 -0600, Aaron Toponce wrote:
> How does this compromise security when you're the only member of your
> private group?
And if you are not?
Why should you? Well someone simply might not want to use UPG? Or might
use the users or staff group?

Or do "we" now basically force everybody to use UPG?

Or do we patch ssh to detect whether it runs in an UPG/non-UPG
environment? I really wonder whether such a patch would be merged
upstream...


> Setting any permission bit on any file on any computer won't protect you
> from social engineering, so I fail to see where you're going with your
> argument.
I'm really speechless...

Well then,.. move on


> 581919 was created, because the write bit should be set on the ~/.ssh/
> directory, and contents,
Wonder if upstream agrees

>  seeing as though Debian is a UPG-based
> operating system.
Is it? Again,... speechless...
But I guess it improves the "overall experience"... if we force users in
one give corset...
.oO(Perhaps we should drop KDE, and declare Debian to be
GNOME-only-based)


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: UPG and the default umask

[Michael Banck]

On Mon, May 17, 2010 at 07:10:14PM +0200, Christoph Anton Mitterer wrote:
> 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).

Reading the discussion in #314347, it looks like permission checks will
only get relaxed on UPG systems, which sounds sane to me.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100517180843.gc3...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Aaron Toponce]

On 05/17/2010 11:46 AM, Christoph Anton Mitterer wrote:
> If you need to change for example ssh, to allow an authorized_keys file
> or perhaps even things like ~/.ssh/id_rsa to be group-readable and/or
> writable you actively compromise security, at least for those systems
> which do not use (for whatever reason) UPG.

How does this compromise security when you're the only member of your
private group?

> I guess upstream haven't added that permissions checks just because life
> was so boring, but rather for some specific reason.
> In the case of authorized_keys, I assume, to prevent "social
> attacks" if you know which people are allowed to access a machine,
> it's much easier to get their keys...

Setting any permission bit on any file on any computer won't protect you
from social engineering, so I fail to see where you're going with your
argument.

> Or do I understand the idea behind 581919 wrongly?

581919 was created, because the write bit should be set on the ~/.ssh/
directory, and contents, seeing as though Debian is a UPG-based
operating system. The only user of the private group is the owner of the
file itself. This was the reason for 314347, as SVN was behaving
unexpectedly. Thus, a regression.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Mon, 2010-05-17 at 11:23 -0600, Aaron Toponce wrote:
> You haven't shown any implementation that security will be compromised
> in any way. You just keep throwing it around, which isn't doing anything
> for the discussion.
Uhm, no!

If you need to change for example ssh, to allow an authorized_keys file
or perhaps even things like ~/.ssh/id_rsa to be group-readable and/or
writable you actively compromise security, at least for those systems
which do not use (for whatever reason) UPG.

I guess upstream haven't added that permissions checks just because life
was so boring, but rather for some specific reason.
In the case of authorized_keys, I assume, to prevent "social
attacks" if you know which people are allowed to access a machine,
it's much easier to get their keys...

Or do I understand the idea behind 581919 wrongly?


Beset wishes,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: UPG and the default umask

[Harald Braumann]

On Mon, May 17, 2010 at 11:04:58AM -0600, Aaron Toponce wrote:

> If you're using a non-UPG system, then you don't care. Debian is
> UPG-based, so your argument is invalid.

So you propose that Debian should be restricted to work in pure UPG
environments. Then there is no need to detect the environment and you
can just set a fixed umask.

If, however, we contemplate the thought that it might be desirable for
Debian to continue to work in other environments, then I think my
arguments are valid. And I think I have shown that it is not possible
to detect the specifics of that environment. No matter how much magic
you put into it. So again, you have to just set a fixed umask, because
everything would just be esotericism and not based on any rational reasoning.

Cheers,
harry




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517173746.gg4...@sbs288.lan

Re: UPG and the default umask

[Aaron Toponce]

On 05/17/2010 11:10 AM, Christoph Anton Mitterer wrote:
> 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).

You haven't shown any implementation that security will be compromised
in any way. You just keep throwing it around, which isn't doing anything
for the discussion.

> On Mon, 2010-05-17 at 11:04 -0600, Aaron Toponce wrote:
>> If you're using a non-UPG system, then you don't care. Debian is
>> UPG-based, so your argument is invalid.
> You actually, have to care... at least if #581919 is "solved".

581919 is a regression from 314347. It should be fixed just on that basis.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[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,...

On Mon, 2010-05-17 at 11:04 -0600, Aaron Toponce wrote:
> If you're using a non-UPG system, then you don't care. Debian is
> UPG-based, so your argument is invalid.
You actually, have to care... at least if #581919 is "solved".


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: UPG and the default umask

[Aaron Toponce]

On 05/17/2010 10:49 AM, Harald Braumann wrote:
> On Mon, May 17, 2010 at 10:14:28AM -0600, Aaron Toponce wrote:
>> On 05/17/2010 10:02 AM, Harald Braumann wrote:
>>> - you could have a UPG system but a mismatch of IDs -> wrong umask
>>
>> ID numbers, yes. ID names, no. If the user name maches the group name,
>> IE: aaron = aaron, then the user matches the private group. If the match
>> is not made, then umask 0022 should be in play.
> 
> from pam_umask's description of the usergroups option:
> 
> If the user is not root, and the user ID is equal to the group ID, *and*
> the username is the same as primary group name, the umask group bits
> are set to be the same as owner bits (examples: 022 -> 002, 077 ->
> 007). 
> 
> So if there is a mismatch of *either*, name or ID, then pam_umasks
> detects a non-UPG system, while it might very well be all UPG.

A bug in pam_umask.so that needs to be addressed (which I believe we've
already started addressing in this thread).

> Also,
> just because Debian's adduser happens to give the same name to the
> user as well as to his private group, this is not necessarily true in
> all system. You could have group names that are prefixed with "grp",
> or whatever, but still have a perfectly valid UPG system.

Can you produce a valid example? The definition of UPG is to create a
group name that is the same as the username. If the system in question
is using UPG, then there won't be any conflicts, unless the
admiinstrator tries creating a "adm" user, or something equally as unsound.

>> If the username matches the group name, then you have a UPG system.
> 
> And on what assumptions do you base this conclusion? 

This is how UPG works. A new user is added to the system, and a group of
the same name is also added to the system. This is fundamental to UPG.

>> Unless you created a user called "devel" and put him in the "devel"
>> group. Debian is not substitute for stupidity.
> 
> How is that stupid? Users and groups are completely seperate name
> spaces, so why would I care in a non-UPG system?

If you're using a non-UPG system, then you don't care. Debian is
UPG-based, so your argument is invalid.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Harald Braumann]

On Mon, May 17, 2010 at 10:14:28AM -0600, Aaron Toponce wrote:
> On 05/17/2010 10:02 AM, Harald Braumann wrote:
> > - you could have a UPG system but a mismatch of IDs -> wrong umask
> 
> ID numbers, yes. ID names, no. If the user name maches the group name,
> IE: aaron = aaron, then the user matches the private group. If the match
> is not made, then umask 0022 should be in play.

from pam_umask's description of the usergroups option:

If the user is not root, and the user ID is equal to the group ID, *and*
the username is the same as primary group name, the umask group bits
are set to be the same as owner bits (examples: 022 -> 002, 077 ->
007). 

So if there is a mismatch of *either*, name or ID, then pam_umasks
detects a non-UPG system, while it might very well be all UPG. Also,
just because Debian's adduser happens to give the same name to the
user as well as to his private group, this is not necessarily true in
all system. You could have group names that are prefixed with "grp",
or whatever, but still have a perfectly valid UPG system.

> > - you could have a non-UPG system but a user's name and ID happen to
> >   match those of the group -> wrong umask
> 
> If the username matches the group name, then you have a UPG system.

And on what assumptions do you base this conclusion? 

> Unless you created a user called "devel" and put him in the "devel"
> group. Debian is not substitute for stupidity.

How is that stupid? Users and groups are completely seperate name
spaces, so why would I care in a non-UPG system?

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517164957.gf4...@sbs288.lan

Re: UPG and the default umask

[Aaron Toponce]

On 05/17/2010 10:02 AM, Harald Braumann wrote:
> - you could have a UPG system but a mismatch of IDs -> wrong umask

ID numbers, yes. ID names, no. If the user name maches the group name,
IE: aaron = aaron, then the user matches the private group. If the match
is not made, then umask 0022 should be in play.

> - you could have a non-UPG system but a user's name and ID happen to
>   match those of the group -> wrong umask

If the username matches the group name, then you have a UPG system.
Unless you created a user called "devel" and put him in the "devel"
group. Debian is not substitute for stupidity.

> - you could add more layers and check, e.g., if the user is the only
>   member in the group. but more users could be added later making the
>   first user's files writeable by those.
> 
> No matter how much clever logic you put in there, there is simply no
> way to make this work reliably because it's based on wrong assumption.

There is no complex, additional layers to check. You only need to match
the user and group names. If they match, it's UPG. If they don't, it
isn't. Give me a realistic case where this would be problematic.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Harald Braumann]

On Mon, May 17, 2010 at 01:04:22PM +0200, Bastien ROUCARIES wrote:
> On Mon, May 17, 2010 at 12:26 PM, Harald Braumann  wrote:
> > On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
> >
> >> Will be done in base-files 5.4.
> >
> > I think that this change was done prematurely. There is still the
> > issue of a Debian system running in a non-UPG environment. And so far
> > I haven't seen a resolution for this point in the discussion.
> 
> I believe the pam umask module is the way to go according to
> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html

Fair enough ...

>  [opition] usergroups
> 
> If the user is not root, and the user ID is equal to the group ID,
> and the username is the same as primary group name, the umask group
> bits are set to be the same as owner bits (examples: 022 -> 002, 077
> -> 007).

... but that's the problem. User and group names/IDs are completely
independent from one another and from the group regime emplyed. By no
stretch of imagination can I see how you could deduce the group regime
of a system from those.

- you could have a UPG system but a mismatch of IDs -> wrong umask
- you could have a non-UPG system but a user's name and ID happen to
  match those of the group -> wrong umask
- you could add more layers and check, e.g., if the user is the only
  member in the group. but more users could be added later making the
  first user's files writeable by those.

No matter how much clever logic you put in there, there is simply no
way to make this work reliably because it's based on wrong assumption.

Computer programmes work best when they are based on sound logic. Let's
not part with this tradition. Let's keep the umask fixed at 022 and let
the user change it if he wants.

Cheers,
harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517160223.ge4...@sbs288.lan

Re: UPG and the default umask

[Bernhard R. Link]

* Peter Palfrader  [100517 16:41]:
> The main problem with a default 002 umask, IMHO, is that as soon as you
> copy your files from a host with 002 and usergroups to one without, or
> untar a tarball created on a 002 host with usergroups on a system where
> you don't have a usergroup, Bad Things can happen, depending on the
> exact method you use to copy things.

Every usual copy method should not have that problem (after all, umask
is about bits not to set with any new files explicitly created).

Only way to get something like that is cp -a or tar -xp.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100517154939.ga8...@pcpool00.mathematik.uni-freiburg.de

Re: UPG and the default umask

[Peter Palfrader]

On Mon, 10 May 2010, Aaron Toponce wrote:

> I guess I'm more or less curious why we're still using this outdated
> umask value with UPG. What would it take for Debian to update our
> default umask to match the UPG scheme? Is this doable for Sqeeze? Are
> there reasons for not making the switch?

The main problem with a default 002 umask, IMHO, is that as soon as you
copy your files from a host with 002 and usergroups to one without, or
untar a tarball created on a 002 host with usergroups on a system where
you don't have a usergroup, Bad Things can happen, depending on the
exact method you use to copy things.
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517144058.gh8...@anguilla.noreply.org

Re: UPG and the default umask

[Aaron Toponce]

On 5/17/2010 7:34 AM, Marvin Renich wrote:
> 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.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Marvin Renich]

* Reinhard Tartler  [100517 08:56]:
> Let's have a look at the source. Note that options->usergroups is set
> iff the option "usergroups" is used.
> 
> ,[modules/pam_umask/pam_umask.c]
> | /* Set the process nice, ulimit, and umask from the
> |password file entry.  */
> | static void
> | setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
> |  struct passwd *pw)
> | {
> |   char *cp;
> | 
> |   if (options->usergroups)
> | {
> |   /* if not root, and UID == GID, and username is the same as
> |  primary group name, set umask group bits to be the same as
> |  owner bits (examples: 022 -> 002, 077 -> 007).  */
> |   if (pw->pw_uid != 0 && pw->pw_uid == pw->pw_gid)
> | {
> |   struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
> |   if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
> | {
> |   mode_t oldmask = umask (0777);
> |   umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
> | }
> | }
> | }
> `
> 
> This part of pam seems to match the documentation in pam_umask(8).
> 
> > And it was said in this thread that UID == GID is not always true with
> > UPG. You only need to create a group for that to become false for users
> > you would create afterwards.
> 
> I'd say if Debian's idea of UPG doesn't match pam's, we should either
> change the pam implementation or the implementation of Debian's UPG
> concept to match each other.
> 
> In any case, using pam_umask by default seems to the best approach so far.

This looks like a bug in pam_umask.  UPG has never guaranteed uid=gid.
I'll file a bug.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517133405.gf1...@cleo.wdw

Re: UPG and the default umask

[Philipp Kern]

On 2010-05-17, Timo Juhani Lindfors  wrote:
> Santiago Vila  writes:
>> Ok, what about PAM?
> "UsePAM no" is the default in openssh. I do not know if this is just
> to reduce the attack surface.

While that's true it's not the case for Debian openssh, its postinst adds
UsePAM yes to the configuration on upgrades.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhv2ip3.hdn.tr...@kelgar.0x539.de

Re: UPG and the default umask

[Santiago Vila]

On Mon, 17 May 2010, Timo Juhani Lindfors wrote:

> Santiago Vila  writes:
> > Ok, what about PAM?
> 
> "UsePAM no" is the default in openssh. I do not know if this is just
> to reduce the attack surface.

Grr. We are supposed to be system integrators, but how can we do that
if some parts of the system do not trust the other parts of the system?
That results in useless duplication of work.

Do I really have to put complex code in /etc/profile to use the old
umask when 1 <= uid <= 100?

Instead, we could consider as a bug that a "system user" wants to
login to the system at all.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005171539550.16...@kolmogorov.unex.es

Re: UPG and the default umask

[Aaron Toponce]

On 05/17/2010 07:00 AM, Mike Hommey wrote:
> 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. :)

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: UPG and the default umask

[Mike Hommey]

On Mon, May 17, 2010 at 02:55:20PM +0200, Reinhard Tartler wrote:
> > And it was said in this thread that UID == GID is not always true with
> > UPG. You only need to create a group for that to become false for users
> > you would create afterwards.
> 
> I'd say if Debian's idea of UPG doesn't match pam's, we should either
> change the pam implementation or the implementation of Debian's UPG
> concept to match each other.

There is no such thing as Debian's idea of UPG. There is simply the fact
that when you create a user with UPG, it uses the first uid and the
first gid available. It can happen that they don't match, in the
scenario I gave above. This applies to any distro, afaik.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517130007.ga10...@glandium.org

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 2:22 PM, Santiago Vila  wrote:
> On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
>
>> Santiago Vila  writes:
>> > In either case, if we plan to set default umask in /etc/login.defs or
>>
>> /etc/login.defs is not read when I login to openssh server and it has
>> "UseLogin" set to false. If I enable UseLogin then X11 forwarding
>> stops working [1]. To me it seems that login.defs can not be the only
>> place where umask is set.
>
> Ok, what about PAM?
>
> I would *really* like to drop umask setting from /etc/profile and rely on
> something of lower level, be it login.defs, PAM or whatever.
>
> What would be the steps required to be able to drop umask from /etc/profile?

See
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html

Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=002

And it will work

Regards

Bastien

>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/alpine.deb.1.10.1005171419450.12...@kolmogorov.unex.es
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin1p37y8zke5yt8c8jkoz-fcee9y47jeqnbk...@mail.gmail.com

Re: UPG and the default umask

[Reinhard Tartler]

On Mon, May 17, 2010 at 13:26:04 (CEST), Mike Hommey wrote:

>> I believe the pam umask module is the way to go according to
>> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html
>> 
>>  [opition] usergroups
>> 
>> If the user is not root, and the user ID is equal to the group ID,
>> and the username is the same as primary group name, the umask group
>> bits are set to be the same as owner bits (examples: 022 -> 002, 077
>> -> 007).
>
Let's have a look at the source. Note that options->usergroups is set
iff the option "usergroups" is used.

,[modules/pam_umask/pam_umask.c]
| /* Set the process nice, ulimit, and umask from the
|password file entry.  */
| static void
| setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
|struct passwd *pw)
| {
|   char *cp;
| 
|   if (options->usergroups)
| {
|   /* if not root, and UID == GID, and username is the same as
|primary group name, set umask group bits to be the same as
|owner bits (examples: 022 -> 002, 077 -> 007).  */
|   if (pw->pw_uid != 0 && pw->pw_uid == pw->pw_gid)
|   {
| struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
| if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
|   {
| mode_t oldmask = umask (0777);
| umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
|   }
| }
| }
| 
|   /* See if the GECOS field contains values for NICE, UMASK or ULIMIT.  */
|   for (cp = pw->pw_gecos; cp != NULL; cp = strchr (cp, ','))
| {
|   if (*cp == ',')
|   cp++;
| 
|   if (strncasecmp (cp, "umask=", 6) == 0)
|   umask (strtol (cp + 6, NULL, 8) & 0777);
|   else if (strncasecmp (cp, "pri=", 4) == 0)
|   {
| errno = 0;
| if (nice (strtol (cp + 4, NULL, 10)) == -1 && errno != 0)
|   {
| if (!options->silent || options->debug)
|   pam_error (pamh, "nice failed: %m\n");
| pam_syslog (pamh, LOG_ERR, "nice failed: %m");
|   }
|   }
|   else if (strncasecmp (cp, "ulimit=", 7) == 0)
|   {
| struct rlimit rlimit_fsize;
| rlimit_fsize.rlim_cur = 512L * strtol (cp + 7, NULL, 10);
| rlimit_fsize.rlim_max = rlimit_fsize.rlim_cur;
| if (setrlimit (RLIMIT_FSIZE, &rlimit_fsize) == -1)
|   {
| if (!options->silent || options->debug)
|   pam_error (pamh, "setrlimit failed: %m\n");
| pam_syslog (pamh, LOG_ERR, "setrlimit failed: %m");
|   }
| }
| }
| }
| 
`

This part of pam seems to match the documentation in pam_umask(8).

> And it was said in this thread that UID == GID is not always true with
> UPG. You only need to create a group for that to become false for users
> you would create afterwards.

I'd say if Debian's idea of UPG doesn't match pam's, we should either
change the pam implementation or the implementation of Debian's UPG
concept to match each other.

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

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87hbm64rif@faui44a.informatik.uni-erlangen.de

Re: UPG and the default umask

[Timo Juhani Lindfors]

Santiago Vila  writes:
> Ok, what about PAM?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/844oi6k7x6@sauna.l.org

Re: UPG and the default umask

[Santiago Vila]

On Mon, 17 May 2010, Timo Juhani Lindfors wrote:

> Santiago Vila  writes:
> > In either case, if we plan to set default umask in /etc/login.defs or
> 
> /etc/login.defs is not read when I login to openssh server and it has
> "UseLogin" set to false. If I enable UseLogin then X11 forwarding
> stops working [1]. To me it seems that login.defs can not be the only
> place where umask is set.

Ok, what about PAM?

I would *really* like to drop umask setting from /etc/profile and rely on
something of lower level, be it login.defs, PAM or whatever.

What would be the steps required to be able to drop umask from /etc/profile?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.1.10.1005171419450.12...@kolmogorov.unex.es

Re: UPG and the default umask

[Mike Hommey]

On Mon, May 17, 2010 at 01:04:22PM +0200, Bastien ROUCARIES wrote:
> On Mon, May 17, 2010 at 12:26 PM, Harald Braumann  wrote:
> > On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
> >
> >> Will be done in base-files 5.4.
> >
> > I think that this change was done prematurely. There is still the
> > issue of a Debian system running in a non-UPG environment. And so far
> > I haven't seen a resolution for this point in the discussion.
> 
> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517112604.ga9...@glandium.org

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 12:26 PM, Harald Braumann  wrote:
> On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
>
>> Will be done in base-files 5.4.
>
> I think that this change was done prematurely. There is still the
> issue of a Debian system running in a non-UPG environment. And so far
> I haven't seen a resolution for this point in the discussion.

I believe the pam umask module is the way to go according to
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html

 [opition] usergroups

If the user is not root, and the user ID is equal to the group ID,
and the username is the same as primary group name, the umask group
bits are set to be the same as owner bits (examples: 022 -> 002, 077
-> 007).

Regards

Bastien

>
> Cheers,
> harry
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20100517102642.gd4...@sbs288.lan
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimvltuynodzfpmg3blciewkm9lk9zz8rbzly...@mail.gmail.com

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 10:22 AM, Christoph Anton Mitterer
 wrote:
> On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler 
> wrote:
>> 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?

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

>
> btw3: As this change seems to be decided, wouldn't it make sense to change
> the UMASK value in login.defs and the currently documentation that tells
> some secure values:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 027, or even 077, could be considered better for privacy
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK          022
>
> to the "new" ones with the insecure ones:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 002 is the new default for use with user private groups.
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK          002
>

Using libpam umask will be simplier:
Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=022

Only one place and documented.

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktililnfhaxu7g5chwu32ac1dykgjjsxorwa7v...@mail.gmail.com

Re: UPG and the default umask

[Harald Braumann]

On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:

> Will be done in base-files 5.4.

I think that this change was done prematurely. There is still the
issue of a Debian system running in a non-UPG environment. And so far
I haven't seen a resolution for this point in the discussion.

Cheers,
harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100517102642.gd4...@sbs288.lan

Re: UPG and the default umask

[Holger Levsen]

On Montag, 17. Mai 2010, Christoph Anton Mitterer wrote:
> But I guess non of them wouldn't be received enthusiastically, would they?

you suggested something else in your previous mail...


signature.asc
Description: This is a digitally signed message part.

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Mon, 17 May 2010 10:31:44 +0200, Holger Levsen 
wrote:
> 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.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/b55a9e6f8550f98651d95aea9e5c4...@imap.dd24.net

Re: UPG and the default umask

[Vincent Danjean]

On 16/05/2010 16:46, Aaron Toponce wrote:
> On 05/15/2010 12:16 AM, Vincent Danjean wrote:
>> Somethink is wrong here. Should 314347 be reopened ?
> 
> Agreed. It's not working as it should. Running openssh-client version
> 1:5.5p1-3, and setting the write bit on my private group seems to keep
> the client from behaving as expected.

I just opened a new bug (d-devel is in CC) as 314347 is about openssh-client
and this problem is in openssh-server. However, the fix is probably similar.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf0ff4e.4090...@free.fr

Re: UPG and the default umask

[Holger Levsen]

Hi,

On Montag, 17. Mai 2010, Christoph Anton Mitterer wrote:
> May I suggest the following:

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


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler 
wrote:
> 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.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/17db8d7d1bc34528f0eea9fa032ab...@imap.dd24.net

Re: UPG and the default umask

[Timo Juhani Lindfors]

Santiago Vila  writes:
> In either case, if we plan to set default umask in /etc/login.defs or

/etc/login.defs is not read when I login to openssh server and it has
"UseLogin" set to false. If I enable UseLogin then X11 forwarding
stops working [1]. To me it seems that login.defs can not be the only
place where umask is set.

[1] man sshd_config:

"Specifies whether login(1) is used for interactive login sessions.
The default is ``no''.  Note that login(1) is never used for remote
command execution. Note also, that if this is enabled, X11Forwarding
will be disabled because login(1) does not know how to handle xauth(1)
cookies."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84d3wvj7e5@sauna.l.org