FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-11-2008, 03:14 PM
"Carl Fürstenberg"
 
Default RFC: Removal of user/groups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per an discussion in IRC about removal of user or groups when purging
packages, I though of asking for comments about a proposal of updating
the policy.

Basically the idea is that, if a package is creating an user or an
group, that is dynamically allocated, then the package may not remove
that user/group when purging the package.

The reason is that, first, for dynamically allocated user/groups, more
than one package might use/create the same user/group.
Second, the package in question might create files using that
user/group during it's execution.
Third, recreating the user/group later might not result in the same ID
(I assume at least).

For static allocated user/groups, I don't think it's a much of a
problem to remove the user/group, as only one package is going to
create that user/group, and it will always have the same ID.

What do you think?

- --
/Carl Fürstenberg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAkh3eOIACgkQPJieVlqrawLZQgCfdTkXZK6WPL 0LP/CvnDy09FOj
hZ8AnA2KXvYJvPserW2E5cRe7epXfGKA
=1uQr
-----END PGP SIGNATURE-----
 
Old 07-11-2008, 03:25 PM
Stephen Gran
 
Default RFC: Removal of user/groups

This one time, at band camp, Carl Fürstenberg said:
> Per an discussion in IRC about removal of user or groups when purging
> packages, I though of asking for comments about a proposal of updating
> the policy.
>
> Basically the idea is that, if a package is creating an user or an
> group, that is dynamically allocated, then the package may not remove
> that user/group when purging the package.
>
> The reason is that, first, for dynamically allocated user/groups, more
> than one package might use/create the same user/group.
> Second, the package in question might create files using that
> user/group during it's execution.
> Third, recreating the user/group later might not result in the same ID
> (I assume at least).
>
> For static allocated user/groups, I don't think it's a much of a
> problem to remove the user/group, as only one package is going to
> create that user/group, and it will always have the same ID.
>
> What do you think?

I think it would be helpful to use the previous 400 discussions of the
same topic as a starting point, and only bring it up again if there are
new arguments.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 07-11-2008, 04:03 PM
"Carl Fürstenberg"
 
Default RFC: Removal of user/groups

On Fri, Jul 11, 2008 at 17:25, Stephen Gran <sgran@debian.org> wrote:
>
> I think it would be helpful to use the previous 400 discussions of the
> same topic as a starting point, and only bring it up again if there are
> new arguments.

Have problem finding such discussion. Do you have any references to
any discussion made the last two years?
--
/Carl Fürstenberg <azatoth@gmail.com>
 
Old 07-11-2008, 04:22 PM
Jonas Meurer
 
Default RFC: Removal of user/groups

On 11/07/2008 Carl Fürstenberg wrote:
> On Fri, Jul 11, 2008 at 17:25, Stephen Gran <sgran@debian.org> wrote:
> >
> > I think it would be helpful to use the previous 400 discussions of the
> > same topic as a starting point, and only bring it up again if there are
> > new arguments.
>
> Have problem finding such discussion. Do you have any references to
> any discussion made the last two years?

http://wiki.debian.org/AccountHandlingInMaintainerScripts might be
helpful.

greetings,
jonas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-12-2008, 02:56 PM
"Carl Fürstenberg"
 
Default RFC: Removal of user/groups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 11, 2008 at 18:22, Jonas Meurer wrote:
> On 11/07/2008 Carl Fürstenberg wrote:
>> On Fri, Jul 11, 2008 at 17:25, Stephen Gran wrote:
>> >
>> > I think it would be helpful to use the previous 400 discussions of the
>> > same topic as a starting point, and only bring it up again if there are
>> > new arguments.
>>
>> Have problem finding such discussion. Do you have any references to
>> any discussion made the last two years?
>
> http://wiki.debian.org/AccountHandlingInMaintainerScripts might be
> helpful.
>
> greetings,
> jonas
>

Thanks Jonas, interesting paper, though it points out problems, it
doesn't discuss any options to handle the problem, except the adduser
is not essential problem.

I was thinking of the reusability problem, and came up with the following:
When an user/group is removed, it's placed in quarantine. That ID
isn't used unless the same user/group is recreated, or that all other
possible ID:s is exhausted. For most of the time, that would prevent
an ID to be used for an other user/group.

- --
/Carl Fürstenberg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAkh4xgIACgkQPJieVlqrawLJ8ACgknymhjcuDh c+hcDywQggmnnR
GWoAn385XL8Vup+NJRFA/xgqz6jD3t4i
=sq0J
-----END PGP SIGNATURE-----
 
Old 07-12-2008, 05:00 PM
The Fungi
 
Default RFC: Removal of user/groups

On Sat, Jul 12, 2008 at 04:56:03PM +0200, Carl Fürstenberg wrote:
[...]
> I was thinking of the reusability problem, and came up with the following:
> When an user/group is removed, it's placed in quarantine. That ID
> isn't used unless the same user/group is recreated, or that all other
> possible ID:s is exhausted. For most of the time, that would prevent
> an ID to be used for an other user/group.

An interesting proposal, to be sure. The first question which arises
is where to track this quarantine information, which needs to be a
mapping of user:uid or group:gid in files somewhere in the system.
For convenience, consider tracking that quarantine information under
the /etc directory in files names "passwd" and "group" respectively.
(Note: sarcasm aside, this would be effectively identical to not
deleting users and groups in the first place.)

I would consider the situation of "all other possible ID:s is
exhausted" to be a corner case not worth optimizing for. If you have
this many system users (Debian's default range provides room for
900, though the admin can easily increase this), it's probably
worthwhile to do some manual cleanup of that machine anyway.

To reiterate other replies, this topic has been discussed ad
nauseum, not only on this list but amongst security-conscious
administrators of Unix-derived systems since, well, the dawn of Unix
(or very close to it, at any rate). Automated deletion or reuse of
IDs is a Bad Idea[TM], since administrator intervention is required
to make absolutely sure no sensitive data is adopted by a new
application.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(fungi@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-12-2008, 05:35 PM
Colin Watson
 
Default RFC: Removal of user/groups

On Sat, Jul 12, 2008 at 04:56:03PM +0200, Carl Fürstenberg wrote:
> I was thinking of the reusability problem, and came up with the following:
> When an user/group is removed, it's placed in quarantine. That ID
> isn't used unless the same user/group is recreated, or that all other
> possible ID:s is exhausted. For most of the time, that would prevent
> an ID to be used for an other user/group.

Isn't this a standard reference counting problem? When adduser --system
is called, have adduser add the calling package to a list of packages
that own that system user; when deluser is called on a system user,
remove the calling package from the list, and only delete the user if
the list becomes empty.

The difficulty, of course, is how to get there from here ...

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-14-2008, 12:38 PM
Gabor Gombas
 
Default RFC: Removal of user/groups

On Sat, Jul 12, 2008 at 04:56:03PM +0200, Carl Fürstenberg wrote:

> I was thinking of the reusability problem, and came up with the following:
> When an user/group is removed, it's placed in quarantine. That ID
> isn't used unless the same user/group is recreated, or that all other
> possible ID:s is exhausted. For most of the time, that would prevent
> an ID to be used for an other user/group.

Not removing the user/group gives you most of the above quarentine
effect, except automatic re-use. OTOH automatic re-use would present
_exactly_ the same issues as normal account removal. So the quarantine
you describe would only help to mask the symptoms but does not provide
any real solution.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-14-2008, 01:03 PM
Gabor Gombas
 
Default RFC: Removal of user/groups

On Sat, Jul 12, 2008 at 06:35:37PM +0100, Colin Watson wrote:

> Isn't this a standard reference counting problem? When adduser --system
> is called, have adduser add the calling package to a list of packages
> that own that system user; when deluser is called on a system user,
> remove the calling package from the list, and only delete the user if
> the list becomes empty.
>
> The difficulty, of course, is how to get there from here ...

Maybe the first step would be to store system user creation/deletion
events at some permanent location. Currently they are logged to syslog;
simply writing the same information to a separate file that is never
rotated would be a start.

We'd also need a "--package" argument to adduser/deluser to also record
the "ownership" of the request.

Once we have such logs small tools could be written that can process
these logs and display orphan users etc. Once there is a common set of
scripts people find useful, they can be integrated back into the adduser
package.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:22 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org