[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
Mike Bird mgb-deb...@yosemite.net 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
On Fri, May 21, 2010 at 04:19:02PM +1000, Ben Finney wrote:
Mike Bird mgb-deb...@yosemite.net 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
Michael Banck mba...@debian.org 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
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
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
On Thu, 20 May 2010 00:22:02 +0200 (CEST), Santiago Vila sanv...@unex.es
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
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
reopen 315089
thanks
On Mon, May 17, 2010 at 11:05 PM, Marvin Renich m...@renich.org wrote:
* Aaron Toponce aaron.topo...@gmail.com [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
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
* Bastien ROUCARIES roucaries.bast...@gmail.com [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
On Tue, May 18, 2010 at 4:16 PM, Harald Braumann ha...@unheit.net 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 ha...@unheit.net wrote:
On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
On 2010-05-18,
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
On Wed, May 19, 2010 at 09:48:41PM +, Christoph Anton Mitterer wrote:
On Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce
aaron.topo...@gmail.com
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
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
Roger Leigh rle...@codelibre.net 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
On 20/05/2010 18:30, Russ Allbery wrote:
Roger Leighrle...@codelibre.net 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
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
Roger Leigh rle...@codelibre.net a écrit :
On 20/05/2010 18:30, Russ Allbery wrote:
Roger Leighrle...@codelibre.net 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
On 20/05/2010 20:44, Bastien ROUCARIÈS wrote:
Roger Leighrle...@codelibre.net 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
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?
Roger Leigh rle...@codelibre.net 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
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
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
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
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
On 2010-05-19, Aaron Toponce aaron.topo...@gmail.com 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
On 05/19/2010 01:00 PM, Philipp Kern wrote:
When I do newgrp group 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,
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
On 2010-05-19, Aaron Toponce aaron.topo...@gmail.com wrote:
On 05/19/2010 01:00 PM, Philipp Kern wrote:
When I do newgrp group 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
On Wed, May 19, 2010 at 3:10 PM, Aaron Toponce aaron.topo...@gmail.com wrote:
On 05/19/2010 01:00 PM, Philipp Kern wrote:
When I do newgrp group 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
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
On 05/19/2010 01:25 PM, James Vega wrote:
Except /etc/profile won't be sourced again unless newgrp - group 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 .
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
On Wed, 19 May 2010 22:51:25 +0200, Willi Mann foss...@wm1.at 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
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
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 Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce
aaron.topo...@gmail.com
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
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
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.
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
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
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
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
On Mon, May 17, 2010 at 3:34 PM, Marvin Renich m...@renich.org wrote:
* Reinhard Tartler siret...@debian.org [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,
On Mon, 17 May 2010, Bernhard R. Link wrote:
* Peter Palfrader wea...@debian.org [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
* Peter Palfrader wea...@debian.org [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
Hi Peter.
On Tue, 18 May 2010 09:48:15 +0200, Peter Palfrader wea...@debian.org
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
On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net 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
[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
On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern tr...@philkern.de
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
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,
On Tue, 18 May 2010 12:32:56 +0200, Christian PERRIER bubu...@debian.org
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
On Tue, May 18, 2010 at 10:49:08AM +, Christoph Anton Mitterer wrote:
On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern tr...@philkern.de
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
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 QA list, you are allowed to do research yourself and
present it here.
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
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 tr...@philkern.de
wrote:
So you present that as universal facts as if you've booked the truth
On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net 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
On 2010-05-18, Harald Braumann ha...@unheit.net 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
On Tue, May 18, 2010 at 3:12 PM, Harald Braumann ha...@unheit.net wrote:
On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net wrote:
Not to speak about, that UPG is anyway a questionable abuse of the
user/group concept.
On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote:
On Tue, May 18, 2010 at 3:12 PM, Harald Braumann ha...@unheit.net wrote:
On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net wrote:
Not to speak about,
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
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
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.
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 ha...@unheit.net [100518 16:16]:
There is already an upstream bug [0], but even if it get's
implemented, that
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
Santiago Vila sanv...@unex.es writes:
In either case, if we plan to set default umask in /etc/login.defs or
/etc/login.defs is not read when I login to openssh server and it has
UseLogin set to false. If I enable UseLogin then X11 forwarding
stops working [1]. To me it seems that login.defs can
On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler fsate...@gmail.com
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
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.
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
On Mon, 17 May 2010 10:31:44 +0200, Holger Levsen hol...@layer-acht.org
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
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.
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.
On Mon, May 17, 2010 at 10:22 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler fsate...@gmail.com
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
On Mon, May 17, 2010 at 12:26 PM, Harald Braumann ha...@unheit.net wrote:
On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
Will be done in base-files 5.4.
I think that this change was done prematurely. There is still the
issue of a Debian system running in a non-UPG
On Mon, May 17, 2010 at 01:04:22PM +0200, Bastien ROUCARIES wrote:
On Mon, May 17, 2010 at 12:26 PM, Harald Braumann ha...@unheit.net wrote:
On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
Will be done in base-files 5.4.
I think that this change was done prematurely.
On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
Santiago Vila sanv...@unex.es writes:
In either case, if we plan to set default umask in /etc/login.defs or
/etc/login.defs is not read when I login to openssh server and it has
UseLogin set to false. If I enable UseLogin then X11 forwarding
Santiago Vila sanv...@unex.es writes:
Ok, what about PAM?
UsePAM no is the default in openssh. I do not know if this is just
to reduce the attack surface.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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,
On Mon, May 17, 2010 at 2:22 PM, Santiago Vila sanv...@unex.es wrote:
On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
Santiago Vila sanv...@unex.es writes:
In either case, if we plan to set default umask in /etc/login.defs or
/etc/login.defs is not read when I login to openssh server and
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
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
On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
Santiago Vila sanv...@unex.es writes:
Ok, what about PAM?
UsePAM no is the default in openssh. I do not know if this is just
to reduce the attack surface.
Grr. We are supposed to be system integrators, but how can we do that
if some parts
On 2010-05-17, Timo Juhani Lindfors timo.lindf...@iki.fi wrote:
Santiago Vila sanv...@unex.es writes:
Ok, what about PAM?
UsePAM no is the default in openssh. I do not know if this is just
to reduce the attack surface.
While that's true it's not the case for Debian openssh, its postinst adds
* Reinhard Tartler siret...@debian.org [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
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 .
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
* Peter Palfrader wea...@debian.org [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,
On Mon, May 17, 2010 at 01:04:22PM +0200, Bastien ROUCARIES wrote:
On Mon, May 17, 2010 at 12:26 PM, Harald Braumann ha...@unheit.net wrote:
On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
Will be done in base-files 5.4.
I think that this change was done prematurely.
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
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
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,
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
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,
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
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
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
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
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
]] 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,
* Aaron Toponce aaron.topo...@gmail.com [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
1 - 100 of 177 matches
Mail list logo
