<story><title>Run0, a systemd based alternative to sudo, announced</title><url>https://mastodon.social/@pid_eins/112353324518585654</url></story><parent_chain><item><author>jimrandomh</author><text>&amp;gt; Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we &lt;i&gt;do&lt;/i&gt; propagate $TERM, but that&amp;#x27;s an explicit exception, i.e. allowlist rather than denylist).&lt;p&gt;I think in practice, this is going to be an endless source of problems, so much so that it won&amp;#x27;t be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn&amp;#x27;t have all the permissions it needs, so you add &amp;quot;sudo&amp;quot; as an adverb.&lt;p&gt;Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in.&lt;p&gt;And sometimes the thing you&amp;#x27;re running is a complicated shell script or shell-script-like object, eg &amp;quot;sudo make install&amp;quot;. In this case, you don&amp;#x27;t really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it&amp;#x27;ll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags.&lt;p&gt;And I&amp;#x27;m kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I&amp;#x27;m particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.</text></item></parent_chain><comment><author>throw0101b</author><text>&amp;gt; &lt;i&gt;And I&amp;#x27;m kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things.&lt;/i&gt;&lt;p&gt;See for example perhaps, &amp;quot;systemd can&amp;#x27;t handle the process previlege that belongs to user name starts with number, such as 0day&amp;quot;:&lt;p&gt;* &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;systemd&amp;#x2F;systemd&amp;#x2F;issues&amp;#x2F;6237&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;systemd&amp;#x2F;systemd&amp;#x2F;issues&amp;#x2F;6237&lt;/a&gt;&lt;p&gt;Never mind that POSIX allows it:&lt;p&gt;* &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pubs.opengroup.org&amp;#x2F;onlinepubs&amp;#x2F;009695399&amp;#x2F;basedefs&amp;#x2F;xbd_chap03.html#tag_03_426&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pubs.opengroup.org&amp;#x2F;onlinepubs&amp;#x2F;009695399&amp;#x2F;basedefs&amp;#x2F;xbd...&lt;/a&gt;&lt;p&gt;* &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pubs.opengroup.org&amp;#x2F;onlinepubs&amp;#x2F;009695399&amp;#x2F;basedefs&amp;#x2F;xbd_chap03.html#tag_03_276&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pubs.opengroup.org&amp;#x2F;onlinepubs&amp;#x2F;009695399&amp;#x2F;basedefs&amp;#x2F;xbd...&lt;/a&gt;&lt;p&gt;&amp;gt; &lt;i&gt;I&amp;#x27;m particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.&lt;/i&gt;&lt;p&gt;For anyone curious, see &amp;quot;Systemd v230 kills background processes after user logs out, breaks screen, tmux&amp;quot; from 2016:&lt;p&gt;* &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11782364&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11782364&lt;/a&gt;</text></comment>
<story><title>Run0, a systemd based alternative to sudo, announced</title><url>https://mastodon.social/@pid_eins/112353324518585654</url></story><parent_chain><item><author>jimrandomh</author><text>&amp;gt; Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we &lt;i&gt;do&lt;/i&gt; propagate $TERM, but that&amp;#x27;s an explicit exception, i.e. allowlist rather than denylist).&lt;p&gt;I think in practice, this is going to be an endless source of problems, so much so that it won&amp;#x27;t be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn&amp;#x27;t have all the permissions it needs, so you add &amp;quot;sudo&amp;quot; as an adverb.&lt;p&gt;Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in.&lt;p&gt;And sometimes the thing you&amp;#x27;re running is a complicated shell script or shell-script-like object, eg &amp;quot;sudo make install&amp;quot;. In this case, you don&amp;#x27;t really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it&amp;#x27;ll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags.&lt;p&gt;And I&amp;#x27;m kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I&amp;#x27;m particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.</text></item></parent_chain><comment><author>yorwba</author><text>I don&amp;#x27;t know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables.&lt;p&gt;The thing you&amp;#x27;re saying is going to be an endless source of problems should already be an endless source of problems! (And I think I&amp;#x27;ve been briefly confused by some missing environment variable once or twice so far.)</text></comment>