<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt'>
<p>On 25/09/2014 06:12, Julien ÉLIE wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
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
<p>That's going backwards...</p>
<p>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.</p>
<p>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).</p>
<p>I last seriously looked at inn, ten years back.</p>
<p>I use another product (which works like normal daemons, start as root, change down to news)</p>
<p>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.</p>