On 5/7/2010 2:33 AM, Paul Wise wrote:
> Other distros are using upstart:
>
> http://upstart.ubuntu.com/
I thought Upstart was on the list for release in Sqeeze. Has this changed?
http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
--
. O . O . O . . O O . . . O .
. . O
Debian, by default, utilizes the user private group scheme (UPG). This
means that when a new user is created on a system, a group of the same
name, if not already in place, is created, and the user is placed in the
group, as the only user. Thus, when new files (dirs, etc) are created by
that user,
On 5/10/2010 10:23 AM, Julien Cristau wrote:
> On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote:
> Are there reasons for making the switch? With user groups, umask 002 or
> 022 doesn't make a difference. To switch off user groups, you set
> USERGROUPS=no in adduser.co
On 5/10/2010 11:24 AM, Drake Wilson wrote:
> FWIW (which is probably vanishingly little), I find that dealing with
> significant group or even inter-user interactions on Unix machines
> eventually gets nearly impossible in the absence of full POSIX ACL
> support. Modern Debian supports this well w
On 5/10/2010 1:07 PM, Klaus Ethgen wrote:
> I still makes sense. The user will not win with the lazier umask but he
> will probably loose security.
>
> See the case the user wants another person in his own group to share
> files. Then he might set the files readable for his group only but not
> fo
On 5/10/2010 4:46 PM, Klaus Ethgen wrote:
> You can never trust anybody for giving him rights to _all_ of your
> files. So this assuming is never true and a user will not have any
> benefit of this group if the umask is 002!
I trust my wife to all of my files.
>> If you don't trust users in your
On 05/11/2010 07:09 PM, Russ Allbery wrote:
> Aaron already explained this, but I was confused for quite some time about
> the point of UPG and I'm not sure I would have gotten it from his
> explanation, so let me say basically the same thing he said in different
> words.
>
> The purpose of UPG is
On 5/13/2010 3:34 AM, Philipp Kern wrote:
> On 2010-05-13, Charles Plessy wrote:
>> If no stronger objections against a change from 022 to 002 is raised, would
>> you
>> agree changing base-files so that /etc/profile uses 002 on new systems?
>
> Doesn't that lead to "great fun" if you activate N
On 5/13/2010 3:48 AM, Santiago Vila wrote:
> Will be done in base-files 5.4.
I just saw the change committed. Thank you very much! This is good news.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O
On 05/14/2010 06:40 PM, Klaus Ethgen wrote:
> Oh, I will not make any more comment to that decision. Maybe I will
> search for a more secure distribution. This decision is much to much.
> And it is the last straw that breaks the camels back. Debian was was my
> favorite distribution for over ten ye
On 05/15/2010 05:26 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
>> for regular users
> Would have to double check it,... but doesn't the current change also
> affect root?
This does, but root is also in his own UPG. If you add any user to the
root
On 05/15/2010 05:50 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
>> This paragraph should be accompanied by something like:
>>
>> Instead of adding users to other users private groups (which has issues as
>> explained above) it is recommend to creat
On 05/15/2010 02:00 AM, Robert Klotzner wrote:
> Also as far as I understood from a previous post, this change will only
> affect
> new installations, not existing ones. So even if a user misunderstood the
> concept and added other users to his private group, this change does not
> affect
> hi
On 05/15/2010 10:47 AM, Santiago Vila wrote:
> On Sun, 16 May 2010, Charles Plessy wrote:
>
>> Also, I have not seen on -devel that the idea of having a different
>> umask for system and regular users has been implemented in
>> base-files yet. I propose to not mention this until base-files is
>> u
On 05/15/2010 02:51 PM, Willi Mann wrote:
> Is it possible to detect whether an account is configured properly based on
> the UPG idea? If yes, wouldn't it then make sense to only set umask 002 if a
> proper UPG account is detected, otherwise 022? This would avoid putting non-
> UPG systems on da
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.
--
. O . O .
On 05/16/2010 12:39 PM, Russ Allbery wrote:
> Because the further discussion was wrong. System users have login shells
> in Debian. (I consider this a very long-standing bug.)
Then the logic should be in play. System users don't necessarily have a
private group, so their umask should be 0022. If
On 05/16/2010 05:11 PM, Santiago Vila wrote:
> They have login shells in the sense that their shell field in /etc/passwd
> is /bin/sh, but if they do not really "login" to the system, then they
> do not read /etc/profile.
>
> In either case, if we plan to set default umask in /etc/login.defs or
>
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 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 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 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
;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 "s
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 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
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 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 - " 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 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 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
On 5/12/2010 1:22 PM, Marcus Better wrote:
> Recently I got the advice [1] to set vm.swappiness to 0, rather than
> the default 60. This improved things dramatically. Apparently Eclipse
> is no longer being swapped out preemptively all the time. The
> difference in perceived responsiveness is spect
Seeing as though upstream Firefox 3.6 released December 1, 2008, and
upstream Thunderbird 3.1 released just a couple days ago, it might be
high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
Icedove 3.1 will depend on it. However, I hear there will be lots of
breakage if xulrunner
On 06/28/2010 02:34 AM, Mike Hommey wrote:
> The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is
> still considered as the release target: iceape 2.0, icedove 3.0, and
> iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support
> for stable will be easier if there i
On 06/29/2010 03:57 AM, Adam Borowski wrote:
> [1]. A Chromium extension named "AdBlock" exists, but it merely hides the
> junk after downloading them -- so you merely don't see them while still
> being subjected to slowdown, having your bandwidth stolen, being tracked,
> having advertising scripts
On 06/29/2010 05:16 AM, Adam Borowski wrote:
> Uhm, and that gets me what? It would nuke all cookies, including those
> which are supposed to last beyond the session.
Touche. I misread your post, and Chromium's ability to do this by
default. Apologies.
--
. O . O . O . . O O . . . O .
.
I just noticed that the chromium-browser package releases in Debian
GNU/Linux unstable are synced version-for-version with the google-chrome
beta package provided by the 3rd party Google Linux repository. Is this
intentional? What's the rationale behind using the beta releases for
chromium-browser
On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
> On 06/30/2010 06:15 AM, Aaron Toponce wrote:
>> I just noticed that the chromium-browser package releases in Debian
>> GNU/Linux unstable are synced version-for-version with the google-chrome
>> beta package provided by the 3
You can see the details outlined in this blog post by Tom Callaway:
http://spot.livejournal.com/315383.html
Long story short: The Sun RPC license that affects this bug has been
re-licensed to the 3-clause BSD license. Even though Debian is moving to
eglibc, this is still good news. Finally time t
The Sun RPC license that has plaqued this bug, has been re-licensed to
the 3-clause BSD license. This affects glibc and krb5-*, and possibly
other packages.
The change from Sun is documented here:
http://blogs.sun.com/webmink/entry/old_code_and_old_licenses
Tom Callaway of Red Hat blogged about
Package: hashcash
Version: 1.21-1
According to the documentation, the hashcash binary supports the '-b
bits' switch and argument for calculating a hashcash token of the size
specified. The default size is 20 bits. The '-b' switch argument
supports an exact size, say '-b 40' for minting a 40 bit to
I'm trying to dig through the archives to see if this has been discussed,
and I'm only finding random one-off discussions here and there about it.
Nothing concrete. If it has already been discussed in great detail, my
apologies.
By default in Debian, when a service package is installed, such as
op
On Fri, Jun 01, 2012 at 07:49:03PM +0100, Philip Hands wrote:
> The reason that RedHat don't start things is that their default approach
> has been to install a whole load of stuff that you might possibly want,
> and allow you to enable it when you are inspired to give some new
> service a try.
>
>
On Fri, Jun 01, 2012 at 08:23:20PM +0200, Jonas Smedegaard wrote:
> Debian goal is - as you probably know already - for packages to work out
> of the box. For daemons this means they are started by default.
>
> If a package (service or not) is insecure by default, it is a bug!
> Severity of suc
On Sat, Jun 02, 2012 at 04:02:57PM +0300, Serge wrote:
> I'm not experienced in this topic much yet, that's why I'm writing not in
> list, but directly. Feel free to reply into list, if you wish.
I would prefer to keep it on the list for a public archive, and to benefit
the greater admin populatio
On Sat, Jun 02, 2012 at 10:43:00PM +0200, Tollef Fog Heen wrote:
> Are you seriously suggesting that DHCP and SSH servers should not listen
> on external interfaces by default? The use case for SSH or DHCPd on
> localhost only is pretty small.
I would much rather have DHCP listening on localhost,
On Sun, Jun 03, 2012 at 02:46:21PM +0800, Chow Loong Jin wrote:
> Is there even a point in having DHCP listening on localhost?
So, why even bother starting it? Thus, the whole point of this thread.
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o
Recently, I decided to put down a Btrfs root on my workstation using the
latest release of the installer. I found that given my hardware
configuration, this is not possible, and would require using another
installer or debootstrap the installation, which is far from ideal.
I have two 250 GB drives
47 matches
Mail list logo
