On Tue, Oct 10, 2006 at 09:31:11PM +0200, Jean Marc Lacroix wrote:
> Ok about the severity for bug, but the bug exist, the exit code 0 is
> reserved for success return only, otherwise it is not possible for calling
> application to know if the service is ok or not.
But the daemon forks and exits before it even attempts to create the sockets,
so there's no way you can communicate that kind of error back.
>> This is not a bug; if you want errors on stderr, use -F. If not, the errors
>> will go to syslog.
> this is not a problem of "-F" option as in the following exemple.
> -> sudo /sbin/rpc.statd --port 126 --outgoing-port 124 -F
> : Could not bind name to socket: Permission denied
That was exactly my point; if you add -F, you get errors on stderr. If not,
you get errors to syslog.
>> If you want your statd to use a privileged port, you must run it as root; do
>> a chown root /var/lib/nfs/sm and this will work.
> In fact, there is no problem on the root permission nor the sudo
> command,
I never claimed you didn't start the daemon as root; I do, however, claim
that statd setuid() to whoever owns the sm directory almost immediately after
the fork.
> but you are right in one very important point, this is about
> the ACL on /var/lib/nfs/sm directory.
You mean the ownership? rpc.statd doesn't understand ACLs.
> So, as there is no more problem on this item, i have now other question ?
>
> Is it normal to make a chown on /var/lib/nfs/sm when changing the port
> number on a socket, i suspect a pb on bad error code when acessing to the
> file system or other ressource , no ?
rpc.statd takes the ownership of /var/lib/nfs/sm as a hint of what user it
should run as; you could call this a bit unorthodox (some would prefer a
configuration file or a command line option instead), but it makes sense, as
it essentially lives within that directory all the time.
Normally, it uses an unprivileged port (> 1024); to bind to a privileged port
in Linux, you'll need to be root. The issue is not that you're _changing_ the
port, it is that you're setting it to something that needs root to bind.
> I think there are a new figure in the testing release ( 1.0.10-1 ), because
> on my lan , i have many host running stable nfs-common with sucess as
> follow.
I'm sorry, I'm unable to understand this sentence.
> -> ps auxwww |grep rpc.statd
> root 5380 0.0 0.1 1788 576 ? Ss Aug18 0:00
> /sbin/rpc.statd --port 126 --outgoing-port 124
> lacroix 362 0.0 0.1 3296 684 pts/2 R+ 21:23 0:00 grep
> rpc.statd
>
> so for me, it seems this is due to a regression or other problem ...
The changelog for 1:1.0.7-10 states:
* Make /var/lib/nfs/{sm,sm.bak,state,rpc_pipefs} be owned by a new "statd"
user (created in postinst), causing rpc.statd to be run as that user
instead of root. (Closes: #240689)
This is not a regression; it's intended behaviour.
> Many thanks for your sugesstion, but this workaround is not acceptable for
> closing this bug.
I'm sorry, but I do not agree that it is a bug. If you want your statd to
run on privileged ports, its user will have to have those privileges. You
can't expect to run Apache as non-root on port 80 either...
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
