Running NUT as a different user on pfSense (FreeBSD)

[mattscaffidi]

On pfSense, NUT is run under the uucp user which is classed as a pseudo-user.

I have special requirements for NUT to SSH into another machine upon an event, defined within upssched cmd - cmd works but ssh with identity keys is hard with a pseudo-user, therefore I must run NUT as another user using the RUN_AS_USER definition.

Upon changing this the implementation of NUT breaks on pfSense for what I can only assume to be a permissions/ownership issue (the driver won’t connect)

Please assist in identifying which files and directories I should be taking ownership of (should this be pid’s too?)

Cheers!

[clepple]

Are you referring to the RUN_AS_USER build-time option (set via ./configure --with-user=username) or the runtime configuration option for upsmon?

If it were me, I would try to leave most of NUT running as the default user, then change only the upsmon user (since that is how upssched is usually launched). upsmon talks to upsd over TCP, so there are no filesystem permissions preventing that from working.

However, the main places where the user ID would need to be changed are any device nodes (serial port or USB), launch scripts for upsd and the driver, and /var/db/nut (where the driver creates its unix-domain socket). I'm not sure how stock my FreeBSD installation is (or how different it might be from pfSense), but it looks like the PID files are created in that directory as well.

lsof can be helpful for debugging permissions issues (to see what the other side of a connection expects).

[mattscaffidi]

Thanks so much for the info.

Yes indeed only the upsmon user, nothing to do with build.

So understood I will take ownership of USB, the upsd executable, and any drivers, and /var/db/nut.

Anything else you suspect? I had difficulty with NUT finding the ups, but I will give it another go tonight....

Cheers

On Tue, 3 Jul 2018 at 9:09 am, Charles Lepple notifications@github.com wrote:

Are you referring to the RUN_AS_USER build-time option (set via ./configure --with-user=username) or the runtime configuration option for upsmon?

If it were me, I would try to leave most of NUT running as the default user, then change only the upsmon user (since that is how upssched is usually launched). upsmon talks to upsd over TCP, so there are no filesystem permissions preventing that from working.

However, the main places where the user ID would need to be changed are any device nodes (serial port or USB), launch scripts for upsd and the driver, and /var/db/nut (where the driver creates its unix-domain socket). I'm not sure how stock my FreeBSD installation is (or how different it might be from pfSense), but it looks like the PID files are created in that directory as well.

lsof can be helpful for debugging permissions issues (to see what the other side of a connection expects).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/568#issuecomment-401982495, or mute the thread https://github.com/notifications/unsubscribe-auth/APK0cdj0KGEz3g8TV2RRJT1rH5CfXvh7ks5uCsQ4gaJpZM4U_mvp .

[clepple]

When you say "take ownership", that applies for USB (which can be done with a devd.conf configuration file - not sure if that made it into ports yet). There is probably a one-time issue with setting the permissions if you install the NUT port after the UPS USB cable has been plugged in, so if /usr/local/etc/devd/nut-usb.conf looks right, try restarting devd and then unplugging and re-plugging the USB cable.

I still think you can do the rest by only changing the upsmon option RUN_AS_USER, and leaving the rest of NUT running as uucp.

However... for the daemons, it would involve adding the appropriate options (-u user for upsd and the driver - see man nutupsdrv for more info on the options common to the latter) to the startup files in /usr/local/etc/rc.d. The daemons are not installed setuid, so they can be owned by root. As you can imagine, this isn't a common use case (the distributions/ports tend to make these decisions based on their particular permission schemes), but if you have a suggestion of how to improve the documentation, feel free to send a patch, and we'll try to work it in.

[dennypage]

Attempting to change the ownership of the USB devices (and all the other NUT infrastructure) is going to be problematic at best. Every time you do an pfSense upgrade or restore, your changes will be overwritten and you will need to reinstall them by hand. And OS upgrades will put you at risk for needing to reengineer the solution from the ground up.

You may want to look at using a suid springboard to launch your ssh session. This gives you a good chance of surviving OS and package upgrades.

[mattscaffidi]

Got it all working guys.

Running NUT as user nut. Everything else such as the drivers etc still runs under root, it is just upsmon which runs under my specified user.

This allows for execution of scripts and ssh sessions, so essentially upon OS upgrade I just need to runs a couple chmod and chown lines and things work as expected.

I can probably set an init script within pfSense to execute this chmod/chown on boot too so it survives OS upgrades.

Cheers for the follow up!

On Tue, 2 Oct 2018 at 11:52 pm, dennypage notifications@github.com wrote:

Attempting to change the ownership of the USB devices (and all the other NUT infrastructure) is going to be problematic at best. Every time you do an pfSense upgrade or restore, your changes will be overwritten and you will need to reinstall them by hand. And OS upgrades will put you at risk for needing to reengineer the solution from the ground up.

You may want to look at using a suid springboard to launch your ssh session. This gives you a good chance of surviving OS and package upgrades.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/568#issuecomment-426327037, or mute the thread https://github.com/notifications/unsubscribe-auth/APK0cfwVHM1nadQzwGcGOL9-fA-_z1_Qks5ug4u8gaJpZM4U_mvp .