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

Peter Selinger selinger at mathstat.dal.ca
Fri Jan 26 04:47:49 CET 2007


Agreed. I didn't realize the user currently can't be specified in
upsd.conf. Since this is so, let's not change it. -- Peter 

Arjen de Korte wrote:
> 
> 
> >> 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
> 




More information about the Nut-upsdev mailing list