On Sat, Mar 01, 2014 at 03:03:17PM +0000, Colin Walters wrote: > On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett > <j...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
