[Nut-upsdev] [nut-Feature Requests][310492] Allow to specify hostnames in ACL (upsd.conf)

[Arjen de Korte]

>> Shall I go ahead and remove the ACL mechanism from the server? And at
>> the same time, change the default LISTEN address to 127.0.0.1 and/or ::1
>> if none is specified?
> sure, please.
> don't forget to update the comment in conf/upsd.conf.sample and
> man/upsd.conf.5

I'll do a search for a couple of keywords that were used by the ACL
mechanism, since it looks like the ACL's are referenced in quite a number
of files. I'm working on a patch, but it will take a couple of days to
finish, since I have some other urgent business to attend to at home...

[...]

>> I doubt that this will make the configuration easier. When it comes to
>> specifying *which* users (username:password) are allowed, it might come
>> in handy. But I don't think we can properly manage the
>> RO/monitoring/slave and RW/commands/master through PAM. So instead of
>> handling this all in one file, would mean that you'd have to configure
>> this in two places. That doesn't really help to make it easier.
> not really since system users already exist.

The users may not have accounts on the box that the server is running on
(in a networked environment for instance), so the above assumption may not
be true. I don't think mandating that they have, is too restrictive. Also,
since usernames and passwords are not encrypted before transmission
(unless SSL is used, but this is not the default) I'm not too thrilled
about the idea of using actual system accounts here. Sure its possible to
create special system accounts for NUT use, but this pretty much defeats
the whole purpose of making configuration easier.

> We only have to declare that for ex. root and arjen have RW right. But
> this only suppress the need of the password in upsd.users.

That's what I meant. We would still need to list the commands/variables
these users are allowed somewhere and I doubt that this can be done
through PAM easily. Your example also illustrates why using system
accounts is not a good idea. It is never a good idea to transmit the root
password of a system in cleartext over the network, not even (or should I
say, especially not) if it is a LAN.

> What I'm not sure about is the need of such a fin granularity in the
> command/var. settings.

That still puzzles me too. I can imagine that one doesn't want to give
each user RW access to a UPS, but it is beyond me why you would want limit
access to just a subset of commands. Or it would be that on a UPS with
multiple outputs, you'd give someone the right to control only one of the
outputs. Anyway, allowing the above pretty much makes having 'upsd.users'
a necessity, so I don't see much benefit in moving the definition of users
and their passwords to PAM.

[...]

> yup, I've already thought about the same: simple things when nothing
> complex is required.

Indeed. So I propose to grant unrestricted RO access on all interfaces
we're listening at. This means that only users with RW access need to be
configured. Any objections?

Best regards, Arjen