[systemd-devel] Using sysusers to setup a new system

[Sébastien Luttringer]

Hello,

On the way to rely on systemd-sysusers to create all users in a fresh Arch
Linux installation, I'm stuck with two issues[1][2].
The key idea was to rely on systemd-users to create them all and start with
empty passwd/group/shadow/gshadow files[3].
So, we moved all base user definitions in a sysusers.d/arch.conf file; or
better into the package which require them.

The first issue[1] is to be able to define the root user shell.
Currently, sysusers.d/basic.conf provides a nologin shell, which prevent root
to login and execute commands (even via sudo). We cannot override the
sysusers.d/basic.conf with a crafted version because systemd-sysusers doesn't
support a shell definition in its format.
As a consequence, I added back root to passwd/group/shadow/gshadow[4].
So, what's the strategy about this? Should root user be an exception and be
defined somewhere else than others users because it requires a valid shell?

The second issue[2] is about the lp group defined in sysusers.d/basic.conf.
Because the cups Arch package set rights on files based on the lp group it
needs a static gid (pacman requirement). lp defined in sysusers.d/basic.conf is
without gid[5], so what's the best way to override it?

Cheers,

Sébastien "Seblu" Luttringer

[1] https://bugs.archlinux.org/task/56017
[2] https://bugs.archlinux.org/task/56818
[3] https://bugs.archlinux.org/task/45196
[4] I love it when a plan comes together ©
[5] https://bugs.archlinux.org/task/55793

[Jérémy Rosen]

Hello Sébastian

Post by Sébastien Luttringer
Hello,
On the way to rely on /systemd-sysusers/ to create *all* users in a
fresh Arch Linux installation, I'm stuck with two issues[1][2].
The key idea was to rely on /systemd-users/ to create them all and
start with empty passwd/group/shadow/gshadow files[3].
So, we moved all base user definitions in a /sysusers.d/arch.conf/
file; or better into the package which require them.
The first issue[1] is to be able to define the root user shell.
Currently, /sysusers.d///basic.conf/ provides a nologin shell, which
prevent root to login and execute commands (even via sudo). We cannot
override the /sysusers.d///basic.conf/ with a crafted version because
/systemd-sysusers/ doesn't support a shell definition in its format.
As a consequence, I added back root to passwd/group/shadow/gshadow[4].
So, what's the strategy about this? Should root user be an exception
and be defined somewhere else than others users because it requires a
valid shell?

sysusers is meant to create only system users, not human users... as
such, it doesn't allow you to set the shell, because system users should
never have a shell. Human users are usually created via some distro tool
at install time (adduser & co)

that's for the philosophical explanation of why you are doing something
that is not meant to be done... now let's be a bit more practical...

root is a very special user in many ways, and one of them is that it is
both a human and a system user... As such I would tend to think that the
proper way to deal with it is to either hardcode it in passwd/group or
to create it at install time.

Not really what you wanted to hear, I know, but root is really special,
and will need special-casing whatever solution you take...

Post by Sébastien Luttringer
The second issue[2] is about the lp group defined in
/sysusers.d///basic.conf/. Because the /cups/ Arch package set rights
on files based on the lp group it needs a static gid (pacman
requirement). lp defined in /sysusers.d///basic.conf/ is without
gid[5], so what's the best way to override it?

hmm, tricky... I see a couple of answers

1) open a RFE on github asking that the lp group be defined in a
base-lp.conf file, so it can be separately overriden (ideally with a patch)
2) just override the systemd-provided basic.conf with arch's version.
You are the distro maintainer, so it's ok to do that.
3) if you don't want to just replace basic.conf, you can create an
archbasic.conf file that would override just the lp group (in case of
double definition the lexicographycally first entry wins, and arch
starts with an a )
    That will cause warnings, but that might be ok, depending on what
your exact constraints are..

Cheers
Jeremy

Post by Sébastien Luttringer
Cheers,
Sébastien "Seblu" Luttringer
[1] https://bugs.archlinux.org/task/56017
[2] https://bugs.archlinux.org/task/56818
[3] https://bugs.archlinux.org/task/45196
[4] I love it when a plan comes together ©
[5] https://bugs.archlinux.org/task/55793
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 AsniÚres-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email ***@smile.fr <mailto:***@smile.fr>
phone [phone]
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire

[Lennart Poettering]

Post by Jérémy Rosen

Post by Sébastien Luttringer
The second issue[2] is about the lp group defined in
/sysusers.d///basic.conf/. Because the /cups/ Arch package set rights on
files based on the lp group it needs a static gid (pacman requirement).
lp defined in /sysusers.d///basic.conf/ is without gid[5], so what's the
best way to override it?

hmm, tricky... I see a couple of answers
1) open a RFE on github asking that the lp group be defined in a
base-lp.conf file, so it can be separately overriden (ideally with a patch)
2) just override the systemd-provided basic.conf with arch's version. You
are the distro maintainer, so it's ok to do that.
3) if you don't want to just replace basic.conf, you can create an
archbasic.conf file that would override just the lp group (in case of double
definition the lexicographycally first entry wins, and arch starts with an a
)
    That will cause warnings, but that might be ok, depending on what your
exact constraints are..

As mentioned, if #3 is the way you want to go, please file a bug if
necessary, so that we can remove any warnings from systemd-sysusers
when two entries are seen for the same user than can be "merged"
without contradictions.

Lennart

[Lennart Poettering]

Post by Sébastien Luttringer
The first issue[1] is to be able to define the root user shell.
Currently, sysusers.d/basic.conf provides a nologin shell, which prevent root
to login and execute commands (even via sudo). We cannot override the
sysusers.d/basic.conf with a crafted version because systemd-sysusers doesn't
support a shell definition in its format.
As a consequence, I added back root to passwd/group/shadow/gshadow[4].
So, what's the strategy about this? Should root user be an exception and be
defined somewhere else than others users because it requires a valid shell?

Hmm, so sysusers.d as the name suggests is intended for system users,
i.e. the users daemon run as which usually have /usr/bin/nologin as
shell. The "root" user is a bit weird in that regard as it kinda is
both a user humans log into, and a user that daemons run as. Right now
we don't really support the part about "human users logging in" in
sysusers.d and I am not sure if we should, but maybe it would be OK to
have a new "p" stanza or so, that allows setting the root
password. But then again, it's a bit strange having the root pw stored
at some place literally...

Note that "systemd-firstboot" is supposed to be a tool for
provisioning an OS image with basic settings before first boot,
including with a root pw. Maybe just using that would be preferable?

Post by Sébastien Luttringer
The second issue[2] is about the lp group defined in sysusers.d/basic.conf.
Because the cups Arch package set rights on files based on the lp group it
needs a static gid (pacman requirement). lp defined in sysusers.d/basic.conf is
without gid[5], so what's the best way to override it?

Hmm, you should be able to simply drop-in a second file with a more
strict definition. sysusers.d should probably merge entries like this,
and not complain unless things are directly contradicting. If it does
complain about it we should probably fix that. In that case, please
file a bug.

Lennart