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

2017-12-26 Thread Lennart Poettering
On Sa, 23.12.17 00:33, Sébastien Luttringer (se...@seblu.net) wrote:

> 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?

> 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

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2017-12-26 Thread Lennart Poettering
On Di, 26.12.17 11:45, Jérémy Rosen (jeremy.ro...@smile.fr) wrote:

> > 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, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2017-12-26 Thread Jérémy Rosen

Hello Sébastian

On 23/12/2017 00:33, Sébastien Luttringer wrote:

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...


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



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
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

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


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

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2017-12-22 Thread 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



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel