Subject: Re: Permissions

From: John Goerzen <[email-masked]>
Date: Wed, 11 Mar 2026 11:27:34 -0500

On Wed, Mar 11 2026, Hadmut Danisch wrote:

> So what is the user nncp and /var/spool/nncp good for, if no one could ever use
> it by design?
>
> Should every single process (postfix, databases,...) which is supposed to send
> files, have it's own nncp configuration and daemon?

That's really up to you.  As a distribution maintainer, I can't be
making presumptions about all those things, especially in the direction
of weakening security by default.

In my own case, for nncpnet, I simply add "user = nncp" in the exim
transport configuration.  

For my Usenet server, I add the news user to the nncp group and make
/var/spool/news setgid.  Perhaps not the best, as the news user can then
read the nncp.hjson file, but I could as easily use sudo to call it
(perhaps I should do that).  In any case, it's a single-use container so
that makes reasonable sense.

> I'm not talking about individual users. I'm talking about several services which
> should send backups, transfer e-mails and so on. Should they share a spool, a
> configuration, and a key, or should they have their own one?

It is up to you.  They could:

- All share the same configuration and be a member of the nncp group.
  Drawbacks is that they could then read the private keys.

- Share the same configruation, but call nncp utilities via sudo.
  Benefits of that are restricting actions to specific nncp commands and
  isolating the private keys from the calling accounts.

- Each have its own nncp installation, which could either directly
  interface with remote systems, or spool up to a local "hub"
  installation via nncp-xfer or regular call/daemon configuration,
  possibly via sudo

UUCP was more prescriptive about system design, in part because it was
from an earlier era where security was thought about differently, and in
part because it required access to shared systemwide resources (modems)
that often were restricted from user accounts.  TCP isn't single-user in
the way a serial line is, so more flexible options are possible with
NNCP.

Incidentally, this is also why I ship example systemd service files for
NNCP but do not activate them by default in the .debs.  There are too
many possible permutations of configurations for me to accurately
anticipate what the user is likely to need.

One could argue that creating the nncp user and group falls into that
category as well, and not without merit.  On the other hand, if somebody
never uses the nncp user and group, it creates no actual change in
system behavior, unlike, say, starting nncp-daemon, which opens a port.

- John