Re: More useful: something like doasedit

2018-02-28 Thread Emille Blanc

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' 
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'.

Re: snmpd improvements

2016-12-21 Thread Emille Blanc

On 16-12-21 9:41 AM, Jan Klemkow wrote:

On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote:
The snmpd.conf can contain static values. If these values

are rewritten/changed over time by rewriting the config,
snmpd needs to be restarted.  Is there a technical reason
for not supporting e.g. reload using HUP?

I'm only looking for input, can provide patches with a bit
of help.  :)

The HUP feature isn't that import for the OpenSNMPd because it does not
cost that much time to reload the information out of the kernel and
the daemon don't keep stat from it's clients.  In the case of the
OpenOSPF its much more important because it take a while to restart.
And during the starting time the router would not be available.

As a frequent user of SNMP, and OpenBSD's snmpd in particular, I could 
see the HUP feature being immensely useful.  Restarting the snmpd daemon 
resets the timeticks value to zero, which appears as a "reboot" to the 
However, in lieu of graceful restart to pick up static changes in 
snmpd.conf, I could see perhaps changing timeticks to reference the host 
system uptime counter instead as an alternative, then restarting it 
would be less of an issue on my end.
However, I'm sure there are legitimate reasons for things to be the way 
they are now, such as portability since everyone's uptime will be 
somewhere different.

Something that's been on my list of things to look at, should I ever 
find my coder hat ever again (it's been missing somewhere for quite some 
time now).

Sometimes all the left hand needs to know is where the right hand is, so it 
knows where to point the blame.