[Nut-upsdev] Re: [nut-commits] svn commit r731

[Arjen de Korte]

>> Maybe we should just open the server sockets after dropping
>> privileges and allow people to override this behavior with a command
>> line switch (I would prefer to parse upsd.conf after dropping
>> privileges too, so automatic detection is not an option).
>
> Ah yes, I agree. Sorry, I just sent my previous email without having
> seen this one.
>
> You have to drop privileges after reading upsd.conf though, because as
> you pointed out, the user to become could be defined in upsd.conf.

No, currently we do not support specifying a user in upsd.conf and maybe
this is for a good reason. As your detailed analysis points out, there
will be a circular dependency if you want to specify a user in upsd.conf:

3 chroot()
4 read upsd.conf as root
5 look up user id <- might fail inside chroot

There are three ways to get around this

1) the user can only be specified on the command line (like we have now)
2) upsd.conf is located outside the chroot'ed environment (similar to what
we do with drivers for instance), which means we can parse it before
chroot'ing
3) copy /etc/passwd inside the jail just before calling chroot

The side effect of 2) is that we won't be able to reload the configuration
file anymore. In case of the drivers (which don't support reloading
either, because they are started with all information from ups.conf on the
command line), I don't think reloading is that important, but for upsd, I
think it is quite useful. Changing this is going to break a lot of init
scripts, so I don't think that's worth it.

Option 3) might be an solution to the above, although many people probably
won't like the idea of having a copy of /etc/passwd living in the
chroot'ed environment for security-by-obscurity reasons.

Adding USER to the upsd.conf is probably not a good idea.

Best regards, Arjen