Debian Developers - Best practices on system users and groups

Author

Best practices on system users and groups

Javier Fernández-Sanguino Peña

2005-10-31, 5:59 pm

After the feedback of the recent d-d thread, I've adapted the section I wrote
on the best practices related to system users and groups, it is currently
available at:
http://www.debian.org/doc/manuals/d...bpp-lower-privs

I would like developers to review and provide feedback for that section,
specially in form of patches. I'm considering doing a bug hunt for:

a) packages that should create a system user for their normal operation and
do not

b) packages that use a system user but do not do handle it properly (for
example, they unconditionally delete the user without checking if the
package, and not the admin, actually created it)

Thoughts?

Javier

Lars Wirzenius

2005-11-01, 8:03 am

ma, 2005-10-31 kello 22:03 +0100, Javier Fern=E1ndez-Sanguino Pe=F1a
kirjoitti:
> After the feedback of the recent d-d thread, I've adapted the section I w=
rote
> on the best practices related to system users and groups, it is currently
> available at:
> http://www.debian.org/doc/manuals/d...est-pkging-pra=
ctices.en.html#s-bpp-lower-privs
>=20
> I would like developers to review and provide feedback for that section,
> specially in form of patches. I'm considering doing a bug hunt for:

DON'T do this:

addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true

When (not if!) addgroup fails, the poor system administrator gets no
indication of it. This is a bug, and a pretty bad one.=20

If adduser isn't quiet enough with --quiet, then fix that, don't hide
real errors. Remove both the redirect and the "|| true".

Also, sticking all the tens of lines of boilerplate code into the
postinst of every package that needs a system user is a good way to
invite trouble. When the boilerplate has a bug (possibly because things
change in the future), it will have to be fixed in dozes on of packages.
It's oh so much more sensible to create a tool that postinsts can call:
if boilerplate code is good enough, then it can easily be abstracted
away.

--=20
Fundamental truth #1: Complexity is the enemy.

sean finney

2005-11-01, 8:03 am

hi javier,

On Mon, Oct 31, 2005 at 10:03:01PM +0100, Javier Fernández-Sanguino Peña wrote:
> I would like developers to review and provide feedback for that section,

thanks for actually putting this into a document, however, i notice
two problems:

- the addgroup/adduser functions mask the error status, yet do not
later check to see if the group was actually created. this is doubly
bad, because not only will the package continue to install, but no
error message or warning is even printed. here's a patch for adding a group:

--- foo 2005-11-01 10:29:15.000000000 +0100
+++ bar 2005-11-01 10:32:27.000000000 +0100
@@ -28,8 +28,13 @@
# 1. create group if not existing
if ! getent group | grep -q "^$SERVER_GROUP:" ; then
echo -n "Adding group $SERVER_GROUP.."
- addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
- echo "..done"
+ addgroup --quiet --system $SERVER_GROUP ||true
+ if ! getent group | grep -q "^$SERVER_GROUP:"; then
+ echo "...error encountered"
+ exit 1
+ else
+ echo "...done"
+ fi
fi

... and the same for adding users.

the second thing i notice is that you arbitrarily modify the user in
question via usermod, which would override the local admin's changes.
i wonder whether it is even good to recommend this at all.

On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote:
> Also, sticking all the tens of lines of boilerplate code into the
> postinst of every package that needs a system user is a good way to
> invite trouble. When the boilerplate has a bug (possibly because things
> change in the future), it will have to be fixed in dozes on of packages.
> It's oh so much more sensible to create a tool that postinsts can call:
> if boilerplate code is good enough, then it can easily be abstracted
> away.

i'd like to double-ack this remark. even if the oft-mentioned "dh_user"
were implemented, if there were a bug in this implementation, every
affected package would have to be /rebuilt/ if the buggy code were
actually in the postinsts.

if you're going to do this, it would be better to provide a program
or a shell library that is sourced in the postinst, and then
awrapper function which does all of this.

sean

--

Olaf van der Spek

2005-11-01, 8:03 am

bWEsIDIwMDUtMTAtMzEga2VsbG8gMjI6MDMgKzAx
MDAsIEphdmllciBGZXJuw6FuZGV6LVNhbmd1
aW5vIFBlw7FhCmtpcmpvaXR0aToKPiBJIHdvdWxk
IGxpa2UgZGV2ZWxvcGVycyB0byByZXZpZXcg
YW5kIHByb3ZpZGUgZmVlZGJhY2sgZm9yIHRoYXQg
c2VjdGlvbiwKPiBzcGVjaWFsbHkgaW4gZm9y
bSBvZiBwYXRjaGVzLiBJJ20gY29uc2lkZXJpbmcg
ZG9pbmcgYSBidWcgaHVudCBmb3I6Cgo+IFR5
cGljYWxseSB0aGlzIG1lYW5zIHRoYXQgdGhlIGNv
bmZpZ3VyYXRpb24gZmlsZXMgYXJlIG93bmVk
IGJ5IGdyb3VwLCBiZWxvbmcgdG8gdGhlIGdyb3Vw
IG9mIHRoZSBzeXN0ZW0gdXNlciBhbmQgYXJl
IG1vZGUgMDY0MC4KCk93bmVkIGJ5IGdyb3VwPyBX
aGF0IGdyb3VwPwoKPiBJZiB0aGUgZGFlbW9u
IGxvZ3MgdG8gYSBkaXJlY3RvcnkgdW5kZXIgL3Zh
ci9sb2cvIHRoZW4gKml0KiBzaG91bGQgYmUg
b3duZWQgYnkgdGhlIHN5c3RlbSB1c2VyIGFuZCBy
b3RhdGVkIGxvZyBmaWxlcyBuZWVkIG5vdCBi
ZSBjaGFuZ2VkIG93bmVyc2hpcC4KCldoYXQgZG9l
cyAqaXQqIG1lYW4/IFRoZSBkaXJlY3Rvcnkg
b3IgdGhlIGxvZyBmaWxlPwo=

Jonas Meurer

2005-11-01, 8:03 am

On 31/10/2005 Javier Fernández-Sanguino Peña wrote:
> After the feedback of the recent d-d thread, I've adapted the section I wrote
> on the best practices related to system users and groups, it is currently
> available at:
> http://www.debian.org/doc/manuals/d...bpp-lower-privs

the group deletion has currently a problem. From 6.5.1.3 'Removing system
users':

# Remove system group if is a system group
CREATEDGROUP=server_group
if [ -r /etc/adduser.conf ] ; then
FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
else
FIRST_USER_GID=1000
fi
if [ -n "$FIST_USER_GID" ] then
if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
if [ -n "$GROUPGID" ]; then
if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
echo -n "Removing $CREATEDGROUP group.."
delgroup --only-if-empty $CREATEDGROUP || true
echo "..done"
fi
fi
fi
fi

first, the 'if [ -n "$FIST_USER_GID" ] then' should better be
'if [ -n "$FIRST_USER_GID"]; then' (two small typos).

second, and more important, the default GID for the group 'users' is 100
for adduser, so the check above will always fail. system groups created
via 'addgroup --system' have GIDs between 100 and 199.
in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead
of USERS_GID.

...
jonas

Jonas Meurer

2005-11-01, 8:03 am

On 01/11/2005 To Debian-Devel wrote:
> the group deletion has currently a problem. From 6.5.1.3 'Removing system
> users':
>
> # Remove system group if is a system group
> CREATEDGROUP=server_group
> if [ -r /etc/adduser.conf ] ; then
> FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
> else
> FIRST_USER_GID=1000
> fi
> if [ -n "$FIST_USER_GID" ] then
> if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
> if [ -n "$GROUPGID" ]; then
> if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
> echo -n "Removing $CREATEDGROUP group.."
> delgroup --only-if-empty $CREATEDGROUP || true
> echo "..done"
> fi
> fi
> fi
> fi
>
> second, and more important, the default GID for the group 'users' is 100
> for adduser, so the check above will always fail. system groups created
> via 'addgroup --system' have GIDs between 100 and 199.
> in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead
> of USERS_GID.

sorry, i mean LAST_SYSTEM_GID. best would be:

FIRST_SYSTEM_GID=`grep ^FIRST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='`
LAST_SYSTEM_GID=`grep ^LAST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='`
[...]
if [ "$LAST_SYSTEM_GID" -gt "$GROUPGID" ] && [ "$FIRST_SYSTEM_GID" -lt "$GROUPGID" ]; then
[...]
fi

...
jonas

Marc Haber

2005-11-01, 6:11 pm

On Tue, 1 Nov 2005 04:53:33 -0500, sean finney <seanius@debian.org>
wrote:
>if you're going to do this, it would be better to provide a program
>or a shell library that is sourced in the postinst, and then
>awrapper function which does all of this. =20

I would be willing to accept patches for the adduser package (either
for the adduser script itself or for additional scripts) to solve
this.

Greetings
Marc

--=20
-------------------------------------- !! No courtesy copies, please !! =
-----
Marc Haber | " Questions are the | Mailadresse im =
Header
Mannheim, Germany | Beginning of Wisdom " | =
http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 =
72739834

Christian Perrier

2005-11-02, 2:49 am

> Usermod is only called if the user does not exist and the package creates
> it. gdm, PostgreSQL and logcheck already do this. In the example code,
> if the system user exists, then usermod is not called, which is better than
> what logcheck or postgresl currently do.

One very short notice for information: usermod recently got long
options added, similarly to useradd/userdel. This happened in passwd 4.0.13-4

(all utilities in passwd are slowly getting GNU-style long options added)

So, scripts calling it can use more readable options:

bubulle@mykerinos:~/src/debian/dl10n> usermod -h
Usage: usermod [options] LOGIN

Options:
-c, --comment COMMENT new value of the GECOS field
-d, --home-dir HOME_DIR new login directory for the new user account
-m, --move Use -m option to move data to
the new directory
-e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-f, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-g, --gid GROUP force use GROUP as new initial login group
-G, --groups GROUPS list of supplementary groups
-a, --append Use -a option to append the user
to the supplemental groups
-h, --help display this help message and exit
-l, --new-login LOGIN new value of the login name
-L, --lock lock the user account
-o, --non-unique allow using duplicate (non-unique) UID
-p, --password PASSWORD use encrypted password for the new password
-s, --shell SHELL new login shell for the user account
-u, --uid UID new UID for the user account
-U, --unlock unlock the user account

Of course, this is currently possible only in unstable....

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