*** John Goerzen [2021-08-20 07:30]:
>1) Where one main config file isn't desirable.  For instance, individual
>users want to define their own exec commands, areas, etc.

Ah, true. But seems that everyone can have its own configuration file.
However currently I do not know what will happen when others will see
node/area/whatever in his "own" (actually shared) spool unknown to him.
Possibly some panics will occur.

>- More security risks (think of, for instance, a world-readable  set of
>files in /var/mail).  Users have access to the secret  keys and could read
>each other's incoming packets at the very  least.  Or delete them, etc.

In that case I think that any kind of "sharing" (via permissions, via
sudo, whatever) should not be done at all. Possibly only an additional
via-hop should be shared (with intermediate copy/nncp-xfer to transfer
files to it).

Personally I just really do not like sudo. If some nncp-exec target
should be run under some specific user/rules, then I would probably
create an additional user, with his own spool and make him available
through the "via". I really have not met situations where sudo was
necessary. Of course if the task is "run this thing under that user",
then possibly it could not be solved without sudo-like tools, but as a
rule in my practice that tasks are replaced with something completely
different (possibly just some daemon checking some abstract spool
directory for the tasks). So I just have got bias to sudo :-)
And I really would not wish to create shared spool unless everyone
trusts each other -- it is complication that needs *very* complex tools
(sudo) playing with privileges/security. I fear of that :-)

>One reason I am running it as a separate user is because I think that's the
>appropriate way to go, even though I'm the only user on my box.  I wouldn't
>run postfix, exim, apache, tor, etc. as jgoerzen, because the more things
>run as my user, the greater the consequences of a security hole
>exploitation.

Understand, fully agreed and support privilege separation!

>(Yes, I know about things like namespaces and
>capabilities on Linux, but they are Linux-specific and rather complicated.)

There are some kind of similar analogues in BSD-systems I played with
too, but yes -- all of them are very OS/kernel-specific.

>I'm not saying NNCP is bad - far from it!  But basically I want as much
>isolation from every component on my system as possible, and to treat
>everything as untrusted as much as I can, even if I think it's pretty good.

NNCP tries to be dumb and simple :-), but it is really far from, for
example, Postfix'es separated heavily privilege-dropped small daemons.
Basically no privsep and privdrop in mind.

>(/usr/sbin/sendmail is an odd one; setuid root with exim4 and so forth.  I'm
>not fond of this model at all.  Maybe it's better with Postfix.)

When I began to write on C last year, actually I am calmed down about
setuid executables. Basically you just need high (root) privileges for
many syscalls related to privsep-ing and privdrop-ing. Of course, if
developer wrote that code badly -- that could be catastrophic. So all
that stuff requires very high-quality code. And yeah, many OSes has
their specific features allowing you to do high-privileged actions
without necessary setuid-ed root executable, but they are not portable.
Everything here is rather complex :-). And also many things you just can
not do easily (or rather at all!) in Go, that could be done in C, like
using Capsicum framework for example for creating privsep-ed processes.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF