<story><title>Systemd mounted efivarfs read-write, allowing motherboard bricking via &apos;rm&apos;</title><url>https://github.com/systemd/systemd/issues/2402</url></story><parent_chain><item><author>Someone</author><text>The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching &amp;quot;the year of Linux on the desktop&amp;quot; and what some hackers think is best.&lt;p&gt;Nobody sells a chainsaw with safeties disabled, remarking &amp;quot;you can always attach the chain catcher&amp;quot; if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install (&lt;i&gt;(note that you can remount it readonly at boot, simply by adding an entry for it into &amp;#x2F;etc&amp;#x2F;fstab, that is marked &amp;quot;ro&amp;quot;&lt;/i&gt;) is a better idea than mounting it read-only, and requiring those few who need to write these variables to do some extra work by remounting it read-write.</text></item></parent_chain><comment><author>kbenson</author><text>That is an extremely uncharitable reading of what he wrote, and I don&amp;#x27;t think it captures the essence of his intent at all. He said:&lt;p&gt;&amp;gt; Well, there are tools that actually want to write it.&lt;p&gt;It needs to be accessible in some manner.&lt;p&gt;&amp;gt; The ability to hose a system is certainly reason enought to make sure it&amp;#x27;s well protected and only writable to root.&lt;p&gt;Agreement it needs to be guarded, because it&amp;#x27;s a problem if it can hose a system.&lt;p&gt;&amp;gt; But beyond that: root can do anything really.&lt;p&gt;This is a truism for Unix, and altering this is much more of a problem than the occasional bricked machine.  This is free software, and the ability to use it to control our hardware to the fullest extent possible is part of that freedom.  Root cannot and should not be restricted from doing what it needs.  It &lt;i&gt;can&lt;/i&gt;, have hurdles put in place to make it harder to accidentally do something it doesn&amp;#x27;t mean to do though.&lt;p&gt;So, agreement on the problem, and agreement that something needs to be done to fix it, and a caution that access can&amp;#x27;t be entirely closed off without consequences, so root needs access.  What&amp;#x27;s so horrible about that?</text></comment>
<story><title>Systemd mounted efivarfs read-write, allowing motherboard bricking via &apos;rm&apos;</title><url>https://github.com/systemd/systemd/issues/2402</url></story><parent_chain><item><author>Someone</author><text>The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching &amp;quot;the year of Linux on the desktop&amp;quot; and what some hackers think is best.&lt;p&gt;Nobody sells a chainsaw with safeties disabled, remarking &amp;quot;you can always attach the chain catcher&amp;quot; if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install (&lt;i&gt;(note that you can remount it readonly at boot, simply by adding an entry for it into &amp;#x2F;etc&amp;#x2F;fstab, that is marked &amp;quot;ro&amp;quot;&lt;/i&gt;) is a better idea than mounting it read-only, and requiring those few who need to write these variables to do some extra work by remounting it read-write.</text></item></parent_chain><comment><author>JoshTriplett</author><text>If you mount efivarsfs read-only, efibootmgr can&amp;#x27;t make your system bootable.  So at a minimum, you can&amp;#x27;t &lt;i&gt;just&lt;/i&gt; remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it.&lt;p&gt;There&amp;#x27;s no point in mounting efivarsfs read-only; you might as well not mount it at all.</text></comment>