[Nut-upsdev] pidpath, altpidpath, statepath considered muddled or confusing

[Jim Klimov]

Hi,

I looked into this some time back... My reading was that:

* The PIDPATH (for root-owned daemons) could be desired in a secured
location where only root may write (so unprivileged processes running as
`nut`, e.g. random scripts called from upsmon, can not compromise important
stuff - say, replace `upsmon.pid` with a content of `1` so the next `upsmon
-c command` might signal `init` and bring down or otherwise confuse the
OS). As such, daemons that start as not-root or drop privileges early can
not create their PID or socket files there.
* The ALTPIDPATH as commented is for PIDs of non-root daemons (since
recently it is also checked for root daemons as a fallback, I think).
* The STATEPATH is a historic misnomer: a long time ago drivers wrote their
state regularly into a dedicated file which upsd then had regularly read to
post data updates. This was later changed to local sockets, but the name
stuck. I don't think there's anything currently that needs to be persisted
there out of the box; although OS integrations might use the location for
something else (e.g. config snippets, etc. - especially if they may not
write into /etc/nut or similar). This is currently defined as a location
where drivers may write and upsd may read, and the socket files are
generally shared by being readable to the group `upsd` process has. This
allows drivers and the data server to run as different user accounts as
well, intersecting by a group that has limited access to certain paths.
* Also the upsmon POWERDOWNFLAG fits into this question, as it does not
really have to be written into `/etc/killpower` (and having it in the
persistent location can cause issues of its own).
* And security-wise, the `/etc/nut` (or similar) and files expected inside
have a lot of documented recommendations on who should be able to read
what, especially if you run parts of NUT all as different role accounts.
Generally none of the daemons should be able to write there, so a
compromised program can not change configs.
** There is a place for additional tools like augeas and nutconf whose job
is to maintain configs, but they are not daemons and their permissions are
of whoever called them - e.g. root.

Defaults cater to locations that are present or can be made on a majority
of systems, and are intended to be tweaked and tuned to specific distro's
tastes.
Nothing should preclude storing all of these under (/var)/run/nut/*
subdirectories with proper ownership (root/nut), probably created/ensured
by respective init script (if there is no facility like systemd-tmpfiles to
offload the work into).

Jim



On Sun, May 18, 2025 at 1:57 PM Greg Troxel via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> I'm following up on a request from a pkgsrc user to improve the package,
> and that's leading me to thinking part of the issues are in nut, vs the
> package.
>
> Setting aside daemons that run as root vs not, there are two kinds of
> directories, using the BSD hier(7) scheme:
>
>    /var/db/nut:
>      - state files intended to persist across reboots
>
>    /var/run/nut:
>      - pidfiles
>      - (probably) sockets
>
> 1) configure args slightly confusing autoconf vs nut
>
> nut has configure args in two groups; one setting the usual autoconf
> variables not really about nut, and the second group setting state, pid,
> altpid:
>
>   --sharedstatedir=DIR    modifiable architecture-independent data
> [PREFIX/com]
>   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
>   --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
>
>
>   --with-statepath=PATH   path for ups state files (${STATEPATH}, typically
>                           /var/state/ups)
>   --with-altpidpath=PATH  path for NUT driver/upsd .pid files not running
> as
>                           root (<statepath>)
>   --with-pidpath=PATH     Path for root-owned .pid files (${PIDPATH},
>                           typically /var/run)
>
>
> 2) There are some issues; the defaults are hardcoded paths instead of
> following localstatedir and runstatedir
>
>   STATEPATH="/var/state/ups"
>   PIDPATH="/var/run"
>
> but this is minor as packaging will just set them.
>
>
> 3) multiple pid paths confusing and unnecessary
>
> Within BSD/pkgsrc, the rough norm is that each daemon should run
> unprivileged as its own uid/gid, perhaps starting as root and dropping
> when necessary, and that therefore a subdirectory of /var/run is needed
> for pidfiles, so this would be /var/run/nut.  This then needs to be
> created at startup, as /var/run might not have it, or would generally be
> cleared.
>
> Once there is /var/run/nut, then there's no reason to have pidpath and
> altpidpath separated.  I don't see why a single dir that's nutuid:nutgid
> can't be used for both.
>
> 4) statedir unclear
>
> Grepping for statedir via
>
>   find . -name \*.[ch] | xargs egrep -R STATEPATH
>
> I don't end up understanding what if anything is or should be put there.
>
> On my own system, there's a socket for the bestfortress driver, and
> pidfiles for bestfortress, upsd, and upsmon.  All of those belong in
> /var/run/nut, not /var/db/nut, as they are per-system-boot and not used
> across reboots or even nut start/stop.
>
>
> So: am I off here, or is this something to be cleaned up, or ?
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250518/fd9e1957/attachment.htm>