Nut upsuser - Feb 2015 - Install problems (group permissions) with nut 2.7.2

Hmmm...well, let's put it this way.  I'm trying to do the
"right" thing in regards to permissions and access for running NUT and
everything involved with it.  I note in the installation instructions it says
that if you're impatient and want to try starting upsd, upsmon, and drivers
right now, you can use "-u root", but that you should set the correct
permissions later!

I don't fully understand what the correct permissions are, but I had assumed
that it was the reason I had created ups/nut at the beginning.  If adding
"-u root" to each command is bad security policy, then I'd like to
make sure I use a better method.

I've setup NUT several times, and tried following the directions each time,
but no matter what I did...I could not get upsdrvctrl to successfully start
unless I add "-u root" to it (even if I am root when executing the
start command).  The directions don't indicate to do that, so I've
always figured I have permissions incorrect somewhere.  Now I'm finally at
the point where I need to get this right.

Does this revolve around hotplug and udev?  In other words, is the idea that the
created USB device will be in the "nut" group, and thus I'd be
able to tell upsdrvctrl to start if I am user "ups"?   Or do ups/nut
not really play into any of this?

Rob 

> -----Original Message-----
> From: Charles Lepple [mailto:clepple at gmail.com]
> Sent: Tuesday, February 17, 2015 7:26 PM
> To: Rob Groner
> Cc: nut-upsuser List
> Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut
> 2.7.2
> 
> On Feb 17, 2015, at 4:37 PM, Rob Groner <rgroner at RTD.com> wrote:
> 
> > I had thought that giving the user and the group would mean that the
> /usr/local/ups/* directories and binaries created by "make
install" would
> have "nut" as their group, but they don't....they have only
root:root.  Does
> the group permissions not get set in these directories upon install?  I
thought
> that was the point of creating the user and group in the beginning.
> 
> If you want to lock down the binaries to only be readable/executable by
> NUT, you could do that with the group permissions, but since the source
> code to NUT is available, I'm not sure what that buys you (unless you
are
> applying additional transformations on the binaries after installation).
> 
> The restricted user/group IDs are primarily to limit the amount of damage
> that can be done if someone finds a bug in upsd, upsmon or the driver.
> These programs give up root permissions (with the exception of the upsmon
> parent, which calls shutdown), so these are the user/group settings that
they
> will use by default. Also, since the NUT user/group typically does not have
> write access to USB nodes, we recommend using udev rules to set the
> permissions for NUT, which has the side effect of preventing other non-root
> processes from meddling with the UPS.
> 
> --
> Charles Lepple
> clepple at gmail
> 
>

On Feb 18, 2015, at 10:40 AM, Rob Groner <rgroner at RTD.com> wrote:
> Does this revolve around hotplug and udev?
Yes. (Well, technically hotplug was superseded by udev)
>  In other words, is the idea that the created USB device will be in the
"nut" group,
Yes. 
> and thus I'd be able to tell upsdrvctrl to start if I am user
"ups"?   Or do ups/nut not really play into any of this?
The usual startup procedure is to run upsdrvctl as root (such as in a login
script). It will automatically drop the driver to ups/nut.

However, as you mentioned, that requires udev. I don't have an opensuse
system, and the broadband connection is down, so I'm not exactly sure what
you need to do there. On recent Debian and Ubuntu with 2.7.2 and earlier, there
was an issue where the udev rules file needed to be renamed from 62-nut* to
52-nut* in order to not be overridden by another set of rules. It lives
somewhere like /lib/udev/rules.d

Thank you all for the help!

I followed the log messages and found where it had created the udev rule...as
Charles said, in /lib/udev/rules.d.  It is named 52-nut-xxxx and there is
nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d.

I looked at the file and saw how it was laid out...basically an ATTR for every
known USB UPS.  Well, since mine is not a known UPS, I had to add my own entry. 
So I added a similar entry to all the others, but putting in my USB vendor and
product IDs and setting GROUP="nut" (like all the other entries do).

ATTR{idVendor}=="04d8", ATTR{idProduct}=="005c",
MODE="664", GROUP="nut"

But so far as I can tell, when I plug in the USB cable from the UPS...it is
still not setting it to nut group permissions.  I am looking at the file in
/dev/usb/hid/hiddev0 (which goes away when I unplug the UPS).  Either way,
upsdrvctrl still won't start unless I add "-u root".

So I think my udev rule is simply not taking somehow.


Sincerely,
Rob Groner
> -----Original Message-----
> From: Charles Lepple [mailto:clepple at gmail.com]
> Sent: Wednesday, February 18, 2015 8:11 PM
> To: Rob Groner
> Cc: nut-upsuser List
> Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut
> 2.7.2
> 
> On Feb 18, 2015, at 10:40 AM, Rob Groner <rgroner at RTD.com> wrote:
> 
> > Does this revolve around hotplug and udev?
> 
> Yes. (Well, technically hotplug was superseded by udev)
> 
> >  In other words, is the idea that the created USB device will be in
the "nut"
> group,
> 
> Yes.
> 
> > and thus I'd be able to tell upsdrvctrl to start if I am user
"ups"?   Or do
> ups/nut not really play into any of this?
> 
> The usual startup procedure is to run upsdrvctl as root (such as in a login
> script). It will automatically drop the driver to ups/nut.
> 
> However, as you mentioned, that requires udev. I don't have an opensuse
> system, and the broadband connection is down, so I'm not exactly sure
what
> you need to do there. On recent Debian and Ubuntu with 2.7.2 and earlier,
> there was an issue where the udev rules file needed to be renamed from 62-
> nut* to 52-nut* in order to not be overridden by another set of rules. It
lives
> somewhere like /lib/udev/rules.d

On Wednesday, February 18, 2015 08:11:13 PM Charles Lepple wrote:
[...]
> On recent Debian and Ubuntu with 2.7.2 and
> earlier, there was an issue where the udev rules file needed to be
> renamed from 62-nut* to 52-nut* in order to not be overridden by
> another set of rules. It lives somewhere like /lib/udev/rules.d
Charles; I assume this is the message you refered to, so I just checked my 
wheezy at that location, and its already been done. ISTR there was a udev 
update recently.  So wheezy, if up to date, looks to be on top of it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>