Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-27 Thread Christian Seiler
Am 27.01.2015 um 14:46 schrieb Lennart Poettering: > Note that $container_ttys= is actually just a frontend for dynamically > instantiating console-getty@.service instances for the specified > ptys. You can just enable them statically too. No, I can't, because you only support PTY numbers in that

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-27 Thread Lennart Poettering
On Tue, 27.01.15 10:53, Christian Seiler (christ...@iwakd.de) wrote: > 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 sysv

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-27 Thread 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

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-26 Thread Cameron Norman
On Mon, Jan 26, 2015 at 6:08 PM, Lennart Poettering wrote: > On Fri, 23.01.15 19:35, Christian Seiler (christ...@iwakd.de) wrote: > >> - I hope I didn't forget anything > > I spent quite some time to ensuer that systemd systems work > out-of-the-box in container managers. Any container manager th

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-26 Thread Lennart Poettering
On Fri, 23.01.15 19:35, Christian Seiler (christ...@iwakd.de) wrote: > - explicitly enable getty@tty{1,2,3,4}.service Why? This cannot work. The getty services assume a Linux console tty, they will issue ioctls and ansi sequences that only the linux console supports, and do VT management on them

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Christian Seiler
Am 23.01.2015 um 18:57 schrieb Lennart Poettering: >> Am 2015-01-23 08:29, schrieb Mantas Mikulėnas: >>> IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... >>> if thats still a problem, maybe there could be one tmpfs at /run/user, >>> still preventing users from touching root-onl

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 15:45, Christian Seiler (christ...@iwakd.de) wrote: > Am 2015-01-23 08:29, schrieb Mantas Mikulėnas: > >IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... > >if thats still a problem, maybe there could be one tmpfs at /run/user, > >still preventing users from to

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Christian Seiler
Am 2015-01-23 08:29, schrieb Mantas Mikulėnas: IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if thats still a problem, maybe there could be one tmpfs at /run/user, still preventing users from touching root-only /run? Yes, that's a good idea. Initially when posting this

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 09:29, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering > wrote: > > > On Thu, 22.01.15 15:53, Christian Seiler (christ...@iwakd.de) wrote: > > > > > Nevertheless, I think it would be great if this could also be fixed, > > > becau

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Michael Biebl
2015-01-23 8:29 GMT+01:00 Mantas Mikulėnas : > IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if > that's still a problem, maybe there could be one tmpfs at /run/user, still > preventing users from touching root-only /run? FWIW, as long as logind didn't setup per-user tmpfs,

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread David Herrmann
Hi On Thu, Jan 22, 2015 at 3:53 PM, Christian Seiler wrote: > [1] Note that the only other issue I stumbled upon has now been fixed, > so in general I would say that systemd already works really well > in containers without CAP_SYS_ADMIN if you know how to set them > up properly. Jus

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-22 Thread Mantas Mikulėnas
On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering wrote: > On Thu, 22.01.15 15:53, Christian Seiler (christ...@iwakd.de) wrote: > > > Nevertheless, I think it would be great if this could also be fixed, > > because you never know what other applications people might come up > > with. > > > > Th

Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-22 Thread Lennart Poettering
On Thu, 22.01.15 15:53, Christian Seiler (christ...@iwakd.de) wrote: > Nevertheless, I think it would be great if this could also be fixed, > because you never know what other applications people might come up > with. > > The solution would probably be to just add a code path to chown > the direc

[systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-22 Thread Christian Seiler
I've been playing around with systemd on Debian Jessie in CAP_SYS_ADMIN-less and I came upon the following issue[1]: Without CAP_SYS_ADMIN, logind is unable to mount a per-user tmpfs to /run/user/$UID. Relevant journal messages: systemd-logind[48]: Failed to mount per-user tmpfs directory /run/