Oh and such creation/deletion of system users/groups should then
definitely done by some centrally managed code.
This would also allow to easily update things like home-dir, shell or
the GECOS field.
Right now most installations quickly run out of sync, e.g. many legacy
installations will have sy
Hey.
Wouldn't something like the following be a solution:
Apart from some "static" system users/groups which every system has,
let system users be in a certain reserved range, which is not the
normal 1-1000 range but neither a range where normal users can be
created.
When packages try to add the
On Sun, Jul 01, 2012 at 12:35:26PM -0700, Steve Langasek wrote:
> On Sun, Jul 01, 2012 at 11:55:39AM +0200, Marc Haber wrote:
> > > It would also alter the existing behaviour of adduser, which is to
> > > return nonzero if the user already exists, which could cause
> > > breakage.
>
> > NACK
On Sun, Jul 01, 2012 at 11:55:39AM +0200, Marc Haber wrote:
> > It would also alter the existing behaviour of adduser, which is to
> > return nonzero if the user already exists, which could cause
> > breakage.
> NACK, adduser --system does return zero if the user already exists and
> its par
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.
Yes, that would be the way to go for adduser --system
> However, most postinsts wrap the call to adduser with a check f
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
>I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-home \
> --shell
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.
Yes.
> However, most postinsts wrap the call to adduser with a check for
> whether the account already exists,
Which
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> 2) Reinstallation.
>
>I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-h
On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> (culled cc list of a few people I know read -devel)
> Roger Leigh wrote:
>
> > Given the need to consider unlocking as well as locking, I'm not sure
> > it's worth adding special support to deluser: the typical logic used
> > to cr
(culled cc list of a few people I know read -devel)
Roger Leigh wrote:
> Given the need to consider unlocking as well as locking, I'm not sure
> it's worth adding special support to deluser: the typical logic used
> to create the user will be insufficient to unlock, so it's no less
> the effort to
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> > Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
&g
On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not de
* Ian Jackson (ijack...@chiark.greenend.org.uk) [110501 16:39]:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must n
Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > I second your original proposal though, that packages must not delete
> > system users that they have created. I don't think any
On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> I second your original proposal though, that packages must not delete
> system users that they have created. I don't think anyone had objections
> to that, and the question is whether things should be taken further.
I do object to te
On 12/04/11 22:43, Scott Kitterman wrote:
>> Also, we need to provide a way for sysadmin to know they can safely remove
>> a stale
>> system user.
>
> If we could do that, we could just remove them automatically and not
> bother the sysadmin.
Not necessarily. We can't be sure there aren't any fil
On ti, 2011-04-12 at 21:31 +0200, sean finney wrote:
> Hi Lars,
>
> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > > But shouldn't we say they _must_ lock package-specific system users
> > > and groups when the package is removed ?
> >
> > I think that's a good idea. Steve La
> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
>> (Cc to the relevant bug added.)
>>
>> On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote:
>> > Lars Wirzenius writes ("Re: System users: removing them"):
>> > > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph
On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> (Cc to the relevant bug added.)
>
> On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote:
> > Lars Wirzenius writes ("Re: System users: removing them"):
> > > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on
>
Hi Lars,
On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > But shouldn't we say they _must_ lock package-specific system users
> > and groups when the package is removed ?
>
> I think that's a good idea. Steve Langasek in the bug (#621833) and
> others agree, so I think there's
(Cc to the relevant bug added.)
On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: System users: removing them"):
> > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on
> > uids in the range 100-999, to add the following sentence to the end of
>
sean finney writes:
> I was always given the impression that adduser and friends "wanted" to
> be able to handle non-local accounts, but nobody had ever extended it to
> do so? So I think it's a bit shaky to make that assumption.
> But if we specifically limit the scope for users/groups being l
On Sun, Apr 10, 2011 at 11:03:34AM -0700, Russ Allbery wrote:
> sean finney writes:
>
> > For locking the account, I think it could be problematic if you have
> > some kind of central account management system (i.e. LDAP/AD), and you
> > don't want to lock it globally.
>
> Yeah, but adduser does
sean finney writes:
> For locking the account, I think it could be problematic if you have
> some kind of central account management system (i.e. LDAP/AD), and you
> don't want to lock it globally.
Yeah, but adduser doesn't ever do anything with central account management
systems anyway, so far
Hi all,
On Sun, Apr 10, 2011 at 02:25:36AM -0700, Steve Langasek wrote:
> I agree that the accounts should not be deleted, but that the packages
> should still be responsible for certain forms of cleanup:
>
> - removing the user home directory (on purge?)
> - locking the account
> - (optional)
On Sat, Apr 09, 2011 at 10:14:54AM +0100, Roger Leigh wrote:
> On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on
> > uids in the range 100-999, to add the following sentence to the end of
> > the paragraph:
>
Adding a copy to the bug report.
Everyone please Cc 621...@bugs.debian.org if replying to this subhtread.
Thanks.
On la, 2011-04-09 at 10:14 +0100, Roger Leigh wrote:
> On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> > Package: debian-policy
> > Version: 3.9.2.0
> >
> > thanks
Package: debian-policy
Version: 3.9.2.0
thanks
Background for the policy list: see thread starting at
http://lists.debian.org/debian-devel/2011/03/msg01174.html
and continuing in April at
http://lists.debian.org/debian-devel/2011/04/msg00210.html
On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius
28 matches
Mail list logo
