From: Steve Dickson <SteveD@RedHat.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH] nfs-utils - 1 of 6 - statd - drop privs
Date: Thu, 03 Jul 2003 07:42:31 -0400 [thread overview]
Message-ID: <3F0416A7.8020706@RedHat.com> (raw)
In-Reply-To: <16130.30992.260715.7114@gargle.gargle.HOWL>
Hello,
Neil Brown wrote:
>>This first patch allows statd to run as a non-root
>>user. If there is not an rpcuser account (which
>>there is in our world) it will try to use the
>>nobody account.
>>
>>
>
>An effect of this patch is that if someone does a 'make install',
>statd won't work anymore without some chowning.
>
True.... We do an adduser during the package installation...
>What would you think if just getting stat to run as whichever users
>owns /var/lib/nfs, and printing a warning if it is root.
>
Looking around it appears root owns /var/lib/nfs.. and the
point of the patch is not to run a root..... I guess it all comes
do to how secure you want statd.... security is never free.... :)
Maybe you could add a compilation flag allowing people
to control it that way...
>The second patch uses:
> /var/run/rpc.statd/rpc.statd.pid
>as a pid file, which doesn't seem like the right sort of name.
>Either
> /var/run/rpc.statd.pid
>or
> /var/run/nfs/rpc.statd.pid
>
>would seem more appropriate, or is there some RedHat standard you are
>following.
>
I had to make it a directory so the pid file could be removed
after the privs have been dropped (i.e. not longer running as root).
>If we did do a chroot in statd we wouldn't be able to remove the pid
>file any more. We could if it went in /var/lib/nfs, but I don't think
>that is the right place.
>
>Maybe if we held a fd of the pid file open and used ftruncate to
>remove the pid. Would that work ok?
>
The privs dropping patch (i.e the first patch) makes the chroot no longer
necessary... but holding might work but how would the unlink occur?
>And I wish I knew why you thought mountd needed protection against
>SIGPIPE, though I guess it cannot hurt.
>
TCP aborts.... If a sender has a socket open and the receiver close()s the
socket with data still unread, the sender gets a SIGPIPE.
SteveD.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-07-03 11:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-18 17:33 [PATCH] nfs-utils - 1 of 6 - statd - drop privs Steve Dickson
2003-07-02 6:17 ` Neil Brown
2003-07-03 11:42 ` Steve Dickson [this message]
2003-07-04 2:26 ` Neil Brown
2003-07-04 4:26 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F0416A7.8020706@RedHat.com \
--to=steved@redhat.com \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox