rc.news: checking whether we run as the news user

Noel Butler noel.butler at ausics.net
Wed Sep 24 22:33:28 UTC 2014


 

On 25/09/2014 06:12, Julien ÉLIE wrote: 

> Hi all,
> 
> In the rc.news man page, there is a BUGS section that mentions:
> 
> "Running rc.news start as root is never the right thing to do,
> so we should at minimum check for this and error, or perhaps
> change effective user ID."
> 
> I suggest to check whether rc.news is run as another user ID than the "news" user (in all cases, be it start or stop). If it is the case, we exit with the error:
> 
> rc.news should be run as the "news" user
> 
> where "news" is in fact the value of the runasuser keyword in inn.conf (the real news user).
> I don't think we should change effective user ID (if root). It might hide another issue.
> 
> Would this behaviour be OK to do for INN 2.6.0 (CURRENT)?
> I ask because some of you may know use cases where rc.news should be run as root or another user than the news user.
> 
> P.-S.: To be as portable as possible, we should retrieve the current user in a way similar to what we already do in our Makefile.global:
> (whomi || perl -e 'print scalar getpwuid($>), "n"') 2>/dev/null

That's going backwards... 

Being a privileged port it needs somewhere root to open that port, any
starting of any privileged service should be run a root but change to
effective user after starting, its how every other heavily used common
daemon out there works - think httpd, postfix, sendmail, dovecot,
<opposition software>, the list goes on. 

Secondly, given most daemons on servers are started from startup
scripts, it makes more sense to do it this way, the fact inn doesn't has
amazed me for some time. So if moving to a new major version, it makes
more sense to "get with the times" that are less finicky, time proven
standard, and hassle free, especially for new users (I did not comment
on that other previous thread, but that OP made some very good points
about modernising inn to be friendlier, but sadly seems rather than
consider it, it was instantly discarded as too hard basket, well, that's
how it came across anyhow- I note that his problem of limiting
concurrent users will not be solved easily, inn fact maybe not at all
without serious code since he wants IPv6, and most end users get
assigned a /64, how he thinks he can manage that would be interesting). 

Disclaimer: 

I last seriously looked at inn, ten years back. 

I use another product (which works like normal daemons, start as root,
change down to news) 

I am a lurker here because said product may not be suitable in time to
come (related to a previous thread) and I don't want to jump in the deep
end blind folded, so are here to observe and learn in case inn's the way
I decide to move to. 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20140925/894a55f6/attachment.html>


More information about the inn-workers mailing list