[systemd-devel] logind vs CAP_SYS_ADMIN-lessness

[Christian Seiler]

On a general note: the stuff I mentioned that I did to modify the
container was just taken from the lxc-debian template that comes with
LXC 1.0, and I didn't have time to look at it thoroughly to see what's
actually needed there. The stuff I mentioned was more along the lines of
'what I did to get where I was if somebody wanted to reproduce it'
instead of 'I recommend doing that'.

Am 27.01.2015 um 03:08 schrieb Lennart Poettering:
>>  - explicitly enable getty at tty{1,2,3,4}.service
> 
> Why?

Ah, it's nice to see we all live in our own bubbles. :-)

LXC predates systemd by about 2 years. (And at the very beginning,
systemd didn't support containers out of the box, so it predates
systemd's container support by even more.) And at that time, doing that
was a way to sysvinit containers with no or minimal modification to
/etc/inittab. So instead of saying that LXC breaks systemd's
assumptions, you could also say systemd breaks LXC's assumptions. As I
said: bubbles. ;-)

Now I'm not going to argue with you that the method of doing
$container_ttys= isn't vastly superior to what was there previously,
because it is. So I don't disagree with the long-term solution at all.

But LXC 1.0 just doesn't support this yet, so the question is what to do
in the mean time. If I do what I described:

 - logind can't open /dev/tty0, so all VT management in there is
   disabled anyway
 - within systemd: vt_disallocate can't open /dev/tty0, so it just
   returns an error, but that error code is never checked in
   core/execute.c, so it just behaves as if the directive never had
   been there
 - getty at .service statically enabled just runs agetty, so really only
   $TERM is wrong
 - but that was wrong already with sysvinit containers, and I never had
   any major issues because of that

So yeah, it's not pretty, it shouldn't stay in the long run, I
completely agree with your reasoning why you don't like it, but
currently it does seem to 'work'.

That being the case, thinking about it, I actually don't use this
feature myself (with kernels >= 3.12 or so, lxc-attach works quite well,
so I never actually had the need to use a console to log in to a
container, for normal purposes I use SSH anyway), so maybe I'm just
going to deactivate the whole thing in my local config anyway.

Speaking of, isn't there a bug in container-getty at .service?[*] It uses
ConditionPathExists=/dev/pts/%I, starts agetty on pts/%I but sets
TTYPath=/dev/%I instead of /dev/pts/%I... And having the utmp specifier
be just a number (%I) instead of pts/%I is also probably weird.

[*]
http://cgit.freedesktop.org/systemd/systemd/tree/units/container-getty@.service.m4.in

>>  - mask systemd-udevd.service (haven't tested if that's actually needed,
>>    the lxc-debian template also does this however)
> 
> There's no point in doing that. udev uses
> ConditionPathIsReadWrite=/sys anyway, and is automatically skipped
> hence when /sys is read-only.

Ah, good point, so it is in fact not needed. No idea why that's in there
then. Perhaps from a historic attempt when systemd didn't have that
Condition in there?

>>  - touch /etc/fstab if you debootstrap it directly
> 
> You can just remove it. You don't need it in containers (and not even
> on most hosts, unless you actually need to refer to external
> partitions that cannot be auto-configured.

Ah, indeed, just tried it. Interesting, why did I write that? No idea...

>>> I am tempted to just
>>> change nspawn to mount a private tmpfs into /run/user, too, as it
>>> already mounts /run anyway.
>>
>> That would solve /run-quota issues for CAP_SYS_ADMIN-less containers,
>> but is unnecessary (although harmless) for those that do have it.
>
> I decided against doing this after all. [...] Hence, we either do
> something (possibly skipping it it on missing perms) or, we don't do
> it at all, [...]

Fair enough[#], but did you receive my patches for the part about
skipping on missing perms?

http://lists.freedesktop.org/archives/systemd-devel/2015-January/027343.html
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027344.html

[#] One could probably always do --tmpfs=/run/lock:options with nspawn
anyway, if one wants to explicitly do this.

Christian