Re: [nncp-devel] NNCP user/group permissions

From: Sergey Matveev <stargrave_at_domain.hidden>
Date: Tue, 22 Oct 2019 14:32:00 +0300
Message-ID: <20191022113200.GA72960_at_domain.hidden>
Greetings, John!

*** John Goerzen [2019-10-19 22:34]:
>First, thanks for your work on NNCP!  As a guy that used UUCP way back,
>I appreciate a very well-done successor.

Thank you! I was FidoNet point for years and also used UUCP (over SSH)
for many years.

>The question I have pertains to directory ownership and permissions.
>[...]
>In playing around with this a bit, I found that /etc/nncp.yaml has to be
>world-readable (or, at the very least, group-readable if I put all the
>users that are allowed to run nncp commands into an nncp group).
>[...]
>I found a few references in the manual to an nncpuser account but
>nothing very explicit.

Well, actually I have never thought about NNCP used by several users at
once. So there is lack of any recommendations on that subject.

* If users are completely independent, so they have to run their own
  NNCP instances, of course, with their own configuration files and
  private keys. You can easily override hardcoded default NNCP-file
  paths with NNCPCFG, NNCPSPOOL and NNCPLOG environment variables,
  without the need to specify/override them manually for each command
  through -cfg, -spool and -log arguments. However that setup is
  obvious

* In you use-case everything is becoming more complicated. I have also
  tried now to use setgid flag on directories, but it does not work,
  because NNCP code contains hardcoded explicit 0600/0700 permissions. I
  think that it is the problem and NNCP should use more wide 0777/0666
  permissions for all newly created directories and files, because
  anyway umask will be applied after that and end-user/administrator
  will have ability to restrict newly created files anyway he wants

So, I will rewrite all NNCP code creating files/directories and set more
wide file permissions and note about umask and setgid in documentation.
Current code is not friendly for that kind of setup, I agree.

>1) What user/group should own /var/spool/nncp and what should the
>permissions on that directory be?
>
>2) What user/group should own /etc/nncp.yaml and what should the
>permissions on that file be?
>
>3) What user/group should various programs run as?  I would imagine that
>nncp-file should run as individual users but maybe nncp-daemon should
>run as a system nncp user or some such.

Personally I have single-user setup and run/own everything related to
NNCP with my only "stargrave" user on the system. But I tend to think
that separate dedicated user should be created for communication and
tossing tasks. That dedicated user (for example "nncp") will run
nncp-daemon, nncp-call, nncp-toss. I would create separate configuration
file per every user and use that dedicated "nncp" user as a relay
participant. Instead of direct sending to end users, you will write
"via: [my-dedicated-nncp-participant]" in configuration files. Of course
that leads to packets "repacking" under nncp user, but at least his
private key (especially "noiseprv" used for online communication) won't
be accessible to every user in the system. And communication between
dedicated "nncp" user and end-users on the system would go through
shared nncp-xfer's directory. However it will add additional IO of
course. But at least each user will have his own private keypairs, won't
see other ones and none of them will see keypairs used for online
communications.

I think that idea should also be added to documentation with explicit
commands for creating such kind of setup.

>For what it's worth, I am a Debian developer and am also packaging up
>NNCP for Debian.  This will also cause it to be included in Ubuntu and
>other Debian derivatives in the future.

Wow, it would be great for NNCP to appear in the biggest package
repositories! Thank you for you effort!

Unfortunately I am leaving for a vacation and won't be at computer at
least for two weeks. And I can fix all that newly created files issues
and documentation update only after that too.

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

Received on 2019-10-22 11:32:00 UTC

This archive was generated by hypermail 2.4.0 : 2021-02-19 09:13:16 UTC