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 e
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 h
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 li
[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
> listene
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 d
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
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 ef
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/R
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
"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 bein
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 h
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 woul
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
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
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
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 c
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
* 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 a
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-f
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,
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.
>
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 a
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 su
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 100
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
signatur
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 afte
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 UI
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 w
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 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
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 compromi
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
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
tha
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-in
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 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 .
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 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 l
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
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
--
T
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
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
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. Su
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 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
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 magicall
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 sta
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 oth
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"
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 questi
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 abo
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
>
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 m
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
> > > (possibl
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
wi
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 sim
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?
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 featu
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 belie
[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 hap
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 univer
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 (se
* 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 pr
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 sy
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 fr
* 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
> >
]] 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,
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
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 wha
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 w
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_k
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 environ
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 b
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 pa
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 g
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 match
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 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
* 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 ca
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?
T
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 .
* 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
> | se
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 configurati
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 sy
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, 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 matc
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"
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
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
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
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
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 f
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 issu
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.
C
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 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
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
> th
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 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
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 on
1 - 100 of 177 matches
Mail list logo
