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 Mon, May 30, 2011 at 10:47:08AM +0200, Marc Haber wrote:
> On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> > Providing that we have consensus on a recommended strategy for
> > locking and unlocking accounts which can go into policy, I think all
> > we need are examples for h
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
This one time, at band camp, Roger Leigh said:
> 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 s
Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst. However, most
> postinsts wrap the call to adduser with a check for whether the
> account already exists, so it would not be called without an
> update to every pr
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 Thu, 31 Mar 2011 09:23:33 +0100, Lars Wirzenius wrote:
>Would a debhelper tool to create/remove system users be useful? I
>suspect there's only relatively few packages that do that, so perhaps
>not.
I had that discussion years ago with Joey and his comments were the
cause that I submitted patc
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,
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 "
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 t
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
> the paragraph:
>
> Packages must not remov
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
On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> 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/deb
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
Tollef Fog Heen writes:
> - Most or all system accounts are locked and unable to be used for
> login. Perhaps policy should say that user accounts belonging to a
> package must be locked when the package is removed?
Speaking of that, fixing Bug#274229 and the merged bugs for wheezy would
su
]] Lars Wirzenius
Hi,
| I think this would be a good point to have a discussion and set policy
| on how to deal with this. The policy manual seems to currently be silent
| about removing users created by the package at installation time.
|
| * We can decide that packages may not remove th
On to, 2011-03-31 at 14:18 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("System users: removing them"):
> > The easy solution for this would be to never remove the user, but that's
> > also not so clear.
>
> To remove a user and reclaim the uid is a diff
On Thursday, March 31, 2011 04:23:33 AM Lars Wirzenius wrote:
> We have some packages that require a dedicated user to be created, and
> calling "adduser --system" in postinst does that. However, it is not
> always clear whether such users should be removed when the package is
> removed.
>
>
Lars Wirzenius writes ("System users: removing them"):
> The easy solution for this would be to never remove the user, but that's
> also not so clear.
To remove a user and reclaim the uid is a difficult business.
> * Extra accounts are just wasteful, and
We have some packages that require a dedicated user to be created, and
calling "adduser --system" in postinst does that. However, it is not
always clear whether such users should be removed when the package is
removed.
* The user might be administered centrally, via LDAP. (So postinst
31 matches
Mail list logo