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
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
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.
The
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 such
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
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,
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
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
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
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
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 3rd party Google Linux
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/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 is
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 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
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 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 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 .
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
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, no. If the user name maches the group name
, 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
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 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
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
using
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 create
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
him.
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
updated to
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 years
On 5/13/2010 3:34 AM, Philipp Kern wrote:
On 2010-05-13, Charles Plessy ple...@debian.org 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
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 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 UPG,
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 not
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.conf, and that's
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 with
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
for
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
47 matches
Mail list logo
