On 28.02.2018 15:10, Ingo Schwarze wrote:

Felix Maschek wrote on Wed, Feb 28, 2018 at 08:24:19PM +0100:

How would you prevent that something like 'doas vi /etc/fstab' (which will run as root) doesn't offer the user to enter a root shell within vi
(by typing '.sh')?

The sudo(8) utility has become able, over the decades, to do very
complex things and supports fine granularity for assigning rights
to administrators.  As a consequence, it has also become somewhat
large and complicated.  As a consequence, Michael Lucas has become
able to write a book about it and to hold tutorials about it at BSD

The design goal of doas(1) is not to reproduce the full range
of sudo(8) functionality, but to provide a smaller tool that
is easier to maintain, use, and audit.  When writing it, it was
intentional that tedu@ did not include doasedit(1) functionality -
because providing selective editing capabilities of certain
root-owned files to certain non-root administrators is among the
things that can be considered complex, fine-grained control.

During the Cambridge Hackathon, one OpenBSD developer actually
implemented doasedit(1) nevertheless.  But the result was indeed
complicated enough that committing it wasn't a no-brainer, several
developers doubted whether we should have it at all, and nobody
tried very hard to hammer the diff into a form that might meet
consensus for commit.

The question comes up now and again, but not all that often...


I've run into this more than a few times, but found it's easier to just setup sudo for the few cases where needed as a supplement to doas for those cases. I appreciate the idea of leaving the complexity of sudo where it is, and keeping doas neat and tidy. Otherwise, the hardest part in living with doas so far, is coping with muscle memory. 'sudo something' always comes out first, other times 'doas -e /file', both of which make me feel stupid for a brief moment. But that's my problem, not doas'.

Reply via email to