On Thu, 2010-06-03 at 16:34:01 -0400, Chuck Lever wrote: > On 06/ 3/10 04:27 PM, Guillem Jover wrote: > >The second problem is that those files get created by the daemon on > >shutdown, and they *do* follow symlinks. So a user can drop two > >symlinks > >there while the daemon is running and overwrite any file on the file > >system on shutdown. > > > >The fix would consist of passing to configure something like > >“--with-statedir=/var/cache/rpcbind”, and make sure the daemon creates > >such directory if missing on exit in src/warmstart.c:write_struct(), > >which it does not seem to be doing currently. > > > >In addition it would be wise to notify upstream to change the default > >statedir to something else than /tmp. > > Agree changing the upstream default is a good idea. > > Generally, that kind of directory is created as part of installation > (like, by rpm --install) rather than by the daemon itself. At least for /var/run I think it's common for systems to mount it as tmpfs, so the directories might not be there on boot. But those can always be created by the init script (or equivalent), it might be a problem if run from inetd though. > >>Would /var/run (or a subdirectory of it) be a better choice than /tmp ? > > > >/var/run might not be preserved across reboots, but regardless of that I > >think /var/cache is a better fit, it's internal state, but it's used > >to speed up start up time, and can be removed w/o ill effects. > > No, it's not intended to speed start up. > > The cache files aren't really supposed to be retained over a reboot. > After a system restart, all of the RPC services will restart and > register themselves again. If just rpcbind restarts, all that > registration state is lost, so that's the point of saving it in a > file. Ah, yeah that makes more sense! More so given the configure option, I should have written "AFAIS" or something like that. :) > I don't have a preference wrt /var/run or /var/cache. So given that this is actually run time state, /var/run seems more appropriate, indeed. regards, guillem -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
