Am Thu, 01 Jul 2010 09:31:47 +0200
schrieb Goswin von Brederlow :
> The bigger problem is later during boot when you need to wait for all
> devices to appear so /usr, /home, ... can be mounted. One way to solve
> this would be to have the fsck and mounting of filesystems wait for
> the specified t
My perception was that the consensus reached was that we wanted umask
relaxation to be safe.
Bug#583970: pam_umask "usergroups": test if primary group, with
only implicit membership of the user
Closed on Sun, 6 Jun 2010 15:32:43 -0700:
> I don't think this is a check that it makes sense to add
Am Fri, 4 Jun 2010 12:21:56 +0400
schrieb Stanislav Maslovski:
> Well, and how does _your_ proposal implement _full_ choice?
IMHO we are at a place to suggest constructive answers and enhancements
to proposals. Everybody lives happily with things they don't need
nor are affected by.
Regards,
Chr
Am Fri, 4 Jun 2010 02:49:32 +0200
schrieb Petter Reinholdtsen :
> It is possible event baset boot sequencing might make it easier to
> change the ordering, but also there the maintainer of a package need
> to decide on some ordering.
The defined order in /etc/init/cryptdisks-udev.conf is simply "
Am Thu, 3 Jun 2010 00:43:20 +0400
schrieb Stanislav Maslovski :
> > The great thing about Debian is that it can mean and handle so many
> > different things for so many people.
>
> Yes, that is why we should not limit it to a fixed number of
> predefined choices.
Configurable defaults should i
Am Tue, 1 Jun 2010 22:08:19 +0200
schrieb Jonas Meurer:
> should i
> simply tag the bugs as wontfix, describing that a solution is
> impossible?
Some of the setups you describe may work event based using the
current upstart init.
Cheers,
Christian
--
To UNSUBSCRIBE, email to debian-devel-requ
Am Wed, 2 Jun 2010 12:53:03 +0400
schrieb Stanislav Maslovski:
> But why Debian should care about the precise details of local
> admistration policies?
If you have read #248130 and know debian, you probably know local
details are usually nicely configurable. You probably also know about
debconf,
Am Wed, 2 Jun 2010 01:20:00 +0400
schrieb Stanislav Maslovski :
> > But where/how should those things be created best?
>
> Should not be created at all on default installs, thanks.
Do not worry. They are not to be created by default.
If you read the subject it even explicitly reads "optionally
c
If collaboration among users should work nicely out of the box, we will
finally need three small things. I am not sure in which package some of
them should go, though.
1) An install? option to populate /etc/skel/ with the special permission
directories private/(rwx--) and incoming/ (rwsrws-wt
There is another issue related to getting user collaboration working
out of the box:
Users do not belong to the "users" group, thus creating
say /home/group/users as a (sgid) group directory to provide a way for
the users of a system to collaborate on something does not work.
Either adduser woul
Am Mon, 31 May 2010 15:28:20 +0200
schrieb Marc Haber:
> I really like the idea of having all "Debian-exim" accounts with the
> same UID on all systems as this incredibly eases moving things
As Yves suggested, maybe start testing a username => [1000..2]
hash algorithm and conflict resolution
Am Mon, 31 May 2010 12:17:54 +0200
schrieb Harald Braumann:
> > I believe this completes the checks (see below)
>
> I don't, and that is what I meant by wishful thinking. Nowhere is it
> guaranteed that it works this way.
Could you please be a little more specific and try to provide a counter
Am Sun, 30 May 2010 20:13:31 +0200
schrieb Luk Claes:
>
> I guess you should have a deeper look into the possibilities of nss so
> you don't need to sync /etc/passwd and similar files across systems,
Ah thanks, you were thinking NIS networked shared database.
I was thinking, say if I would give
Am Sun, 30 May 2010 09:44:49 -0700
schrieb Mike Bird :
> This would seem to be a trival kernel patch, whether implemented
> alone or together with a /sys control to enable/disable it.
>
> Can anyone see any downside?
I guess the interface would be quite different. Checking the current
umask and
Am Sun, 30 May 2010 15:02:41 +0100
schrieb Stephen Gran :
> There are already well understood mechanisms for ensuring that uids
> are the same across multiple systems. I don't think adduser is the
> place for that.
Do you have a debian pointer maybe?
I am asking because the following suggests a
Am Sat, 29 May 2010 16:51:10 +0200
schrieb Marc Haber :
> hash the user name into the UID since this will - at least on systems
> with only a handful of users - enhance the chance that the same user
> name will get the same UID on different systems.
That could be quite nice, yes.
--
To UNSUBSC
Thank you Harald for scrutinizing.
Am Fri, 28 May 2010 14:50:27 +0200
schrieb Harald Braumann:
> On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote:
> > I'm not sure yet, if I do properly understand the point when/why
> > relaxing conditionally is a bad idea. T
Am Fri, 28 May 2010 08:37:05 +0100
schrieb Roger Leigh:
> Calling getgrgid/getgrnam and
> checking that the user list is empty is *ensuring* that it's private,
> at least at the point in time we check (we can't predict the future).
>
> This check would protect against adding other users to UPGs,
Am Wed, 26 May 2010 08:40:26 +0100
schrieb Stephen Gran:
> first useful argument I've heard for changing adduser's
> behavior. Interoperability with other software is a useful goal,
Would the change have to go into adduser or useradd (part of
base-passwd)?
9.2.1: "Packages other than base-passw
>
> 2) A special case is true: The group is set as the main group of the
>user (in /etc/passwd) while the user is NOT added to his group
>in /etc/groups.
May pam_umask test this, for umask relaxation?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Am Fri, 28 May 2010 00:15:17 +0200
schrieb "C. Gatzemeier" :
> but now, if we
> activate pam_umask, it will read UMASK 022 from login.defs again (and
> relax it conditionally).
err, that is the case if you keep the UMASK 022 and "usergroups"
option (the defaults).
Am Thu, 27 May 2010 11:35:34 +0200
schrieb Wolodja Wentland:
> why not make the decision to use UPG explicit by setting
> "UPG = True"
I would say UPGs are already explicitly used.
If your UPG = True means that newly created users are created with user
private groups, than that is "USERGROUPS=y
Am Tue, 25 May 2010 16:43:21 -0700
schrieb Steve Langasek :
> I am not willing to diverge from upstream on this as this
> would mean admins coming from other systems may get an unpleasant
> surprise when they find that Debian gives a more relaxed umask than
> they were expecting in some corner cas
Wed, 26 May 2010 23:26:37 +0200, Tollef Fog Heen:
> Perhaps addgroup
> shouldn't use the same gid range as what we are using for users, to
> make this problem at least smaller, if not make it go away.
Hm, that may be another option to allign UIDs and GIDs, you'd create
split max. UID/GID amounts t
Am Wed, 26 May 2010 14:25:58 +0200
schrieb Michael Banck :
> On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote:
> > Am Tue, 25 May 2010 22:47:51 +0200
> > schrieb Harald Braumann :
> > > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
> &g
Am Wed, 26 May 2010 18:05:32 +0100
schrieb Roger Leigh :
> How will adduser cope with group addition; does it skip UIDs until
> it finds an unused unique UID/GID pair?
Maybe just skip taken GIDs by default? (every user has one, less gap
more likely to be usable for a user account), starting +1 f
Am Wed, 26 May 2010 18:05:32 +0100
schrieb Roger Leigh :
> What, exactly, does comparing the UID and GID get you? I.e. what
> is is protecting you against? If you're using a system such as
> Debian, which has created a group by the same name for many years,
> you're in no danger
AFAIU it is mea
Am Tue, 25 May 2010 23:30:49 +0100
schrieb Stephen Gran :
> adduser has had bugs filed in the past asking for uid to be equal to
> gid by default, and I have so far rejected them as not worth the
> complexity for the aesthetic pleasure of having numbers match. Is
> there some problem with usernam
Am Tue, 25 May 2010 22:47:51 +0200
schrieb Harald Braumann :
> On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote:
>
> > The
> > path into your home directory is not restricted, just as the path
> > others can take to ring your bell at home is not restricted.
The umask used to be (and should be again now) settable
centrally. (/etc/login.defs or /etc/default/login LSB?)
Setting the umask in /etc/profile and multiple other rc
files (instead centrally in login.defs) was only necessary while
pam_umask was not available, and to be depreciated.
All the tim
Hi,
am glad UPGs and the default umask finally got some momentum.
Technical issues below.
For anybody who has any doubt about UPGs or thinks it's insecure, here
is a explanation snippet from [0]:
~
(This should be true, but still needs the fixes from bel
Am Tue, 18 May 2010 22:36:56 +0200
schrieb Christoph Anton Mitterer :
> Hi.
>
> AFAIK, even Chrome has disabled most tracking stuff per default
> (except those things which FF/etc. do too).
You may be raising a good point.
As it is now: the first thing firefox seems to do when it's run, is to
c
Am Monday 18 October 2004 02:01 schrieb Enrico Zini:
> One problem with diversion could also be that the original package's
> scripts won't probably edit the diverted conffile, but would probably
> edit the file in the traditional place instead.
Same would be the case for admins and users, and th
33 matches
Mail list logo
