On 06/ 3/10 05:07 PM, Guillem Jover wrote:
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.
Sure, that makes sense. Having the daemon create the directory also
means there are fewer ways distributors can get this wrong.
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.
--
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
