On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett <josh@joshtriplett.org> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">---

Strawman proposal, open to suggestions.</div></blockquote>...<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
+  - 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
</div></blockquote><br><div>While I know I *just* posted a mail suggesting that more service state move to unit files... this feels pretty hacky to me.</div><div><br></div><div>Are there any use cases other than screen?</div><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>The per-user runtime dir would stay alive because the headless session would keep the user around.</div><div><br></div>