[systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles

[Josh Triplett]

On Sat, Mar 01, 2014 at 03:03:17PM +0000, Colin Walters wrote:
> On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett
> <josh at joshtriplett.org> wrote:
> >---
> >
> >Strawman proposal, open to suggestions.
> >
> ...
> >
> >+  - Simple conditionals: "C path mode user group -
> >(tmpfiles-line)" does tmpfiles-line if path has mode, user, and
> >group:
> >+    C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775
> >root utmp
> >+    C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755
> >root utmp
> >+    C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777
> >root utmp
> >
> While I know I *just* posted a mail suggesting that more service
> state move to unit files... this feels pretty hacky to me.
> 
> Are there any use cases other than screen?

Games: "if the game has group games and mode 2755...".  But yeah, it
does seem like a hack.  In any case, given that the Debian screen
maintainer ended up accepting another solution instead (telling the
admin to create an overriding /etc/tmpfiles.d file if they change the
permissions, and handling upgrades via postinst), I don't feel strongly
attached to this proposal if nobody sees another useful application for
it.

Besides, inventing a new conditional syntax seems wrong.  Might work
better to introduce a new unit type, foo.tmpfiles, with the full set of
ConditionFoo from unit files, and then add a couple of additional
ConditionFoo types based on data available by statting files.

> I also don't like the idea of admins "configuring" via chmod on
> stuff in /usr/bin.  OSTree simply won't support that for example.

I can't argue with that; I'd personally rather see screen handled via a
set of packages, one per permission model, with the admin installing the
one they want.  Or better yet:

> A lot of this may come back to the discussion about screen and
> sessions.  If for example, users could request a new headless
> session, then most of the screen security-related architecture would
> be completely unnecessary with systemd, since the per-user state
> could just be hooked off of the per-user runtime dir.
> 
> The per-user runtime dir would stay alive because the headless
> session would keep the user around.

I'd certainly love to see a saner implementation of screen multiuser
support that doesn't require root.

- Josh Triplett