Red Hat Bugzilla – Full Text Bug Listing
|Summary:||switch to nfsdcltrack in f18|
|Product:||[Fedora] Fedora||Reporter:||Jeff Layton <jlayton>|
|Component:||nfs-utils||Assignee:||Jeff Layton <jlayton>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||bfields, jlayton, steved|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-06 09:36:24 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jeff Layton 2012-05-07 15:10:10 EDT
Now that we have support for nfsdcld in the kernel and nfs-utils, I'd like to see about switching Fedora to use that in f18. Opening this bug to track the transition and any issues arising from it.
Comment 1 Jeff Layton 2012-05-07 16:00:40 EDT
One thing I'd like to do before turning this on in rawhide is to find a way to have the daemon drop privs after starting up. The problem there is that if someone takes down nfsd and starts it back up, then we need to be able to reopen the pipe. For that (at least currently) we need superuser privileges. A couple of possible solutions... 1) privilege separation. Have the pipe opening be done in a privileged process, and then have it fork and pass the fd of the pipe to a child that drops privs and does everything else. If the pipe needs to be reopened, then the child could die and the parent could reopen the pipe and fork again. 2) use capabilities -- have the child drop everything except CAP_DAC_OVERRIDE permanently, and drop that too temporarily unless it needs to reopen the pipe. Maybe also have it setuid/setgid itself to a non-root user. That's fairly simple to implement so that might be the easiest way to start.
Comment 2 Jeff Layton 2012-05-09 07:26:29 EDT
Ok, I have a patch that I've proposed upstream that has nfsdcld drop all capabilities. I probably will do one more respin of it to update the manpage with the requirements that it imposes, but I think it's good enough for now. I also have a fedora patch that adds nfsdcld to the package and a systemd unit file for it, and makes nfs-server.service depend on it. That seems to work correctly too.
Comment 3 Jeff Layton 2012-09-25 11:34:39 EDT
Moving this out to f19. I'm pondering making this a usermode helper upcall, which would obviate the need for a daemon. Stay tuned...
Comment 4 Jeff Layton 2012-09-28 06:44:31 EDT
Based on great hue and cry from upstream, I'm looking at converting this to a usermodehelper upcall so we won't need to have a running daemon. It doesn't look too hard to do -- most of the sqlite backend code for nfsdcld should just convert right to it. nfsdcld also didn't pass back much info to the kernel, so there's little need for a downcall. So, pushing this out to f19 for now...
Comment 5 Jeff Layton 2012-09-28 08:52:12 EDT
I've started coding up a new program that I'm calling "nfsdcltrack". It uses the same sqlite backend code as nfsdcld, but a simple frontend that just passes info via command line arguments and returns a simple error code. The catch here is that nfsdcld was able to pass a binary struct to userspace, so we didn't have to covert the nfs_client_id4 opaque blob to something that can sit in the argv array. Now we'll need to do some sort of binary to text conversion to send it to userspace. Once we get that text blob to userspace, we can either stick it into the DB as-is, or convert it back to binary. Converting will take a bit more userspace processing initially, but will store more efficiently and will mean that the database would be interchangeable between nfsdcld and nfsdcltrack. It might also mean a more efficient search of the database (not sure on this though).
Comment 6 Jeff Layton 2012-12-04 09:54:46 EST
Looks like steved has added nfsdcltrack to the rawhide package. Now we just need for the kernel patches to get merged into 3.8 and we're good to go.
Comment 7 Jeff Layton 2013-03-06 09:36:24 EST
Well, looks like this actually made f18! The nfsdcltrack binary is part of nfs-utils in f18, and with the release of the 3.8 kernel this is now active. I just confirmed that my unmodified f18 box is using nfsdcltrack now, so I think we can call this closed.