Linux NFS development
 help / color / mirror / Atom feed
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

  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