On Friday 29 January 2016 19:14:58 Richard W.M. Jones wrote: > On Fri, Jan 29, 2016 at 07:25:30PM +0100, Pino Toscano wrote: > > The API for UNIX sockets limits the path to a static size (usually 104 > > or 108 characters, NULL included), which is internally represented as > > UNIX_PATH_MAX. If the temporary directory set is long enough (e.g. > > when running tools as uninstalled, using "run") then these socket paths > > get trucated, if not even cause failures when binding the sockets. > > > > Introduce a new internal API to create paths for sockets, and a new > > helper path where store them in the above case. This new path is created > > only when needed, on a temporary directory under /tmp (hardcoded), and > > cleaned when the handle is destroyed. > > I think reading between the lines, you want to hard code /tmp so that > UNIX_PATH_MAX can never be exceeded, even if the user sets $TMPDIR to > some stupid long path?
That's the idea of the initial approach, yes. Of course that could be changed to use $TMPDIR (or /tmp) as fallback, still failing if even this path would be too long. > Are there machines where /tmp is unusable? /tmp is a mandatory part of FHS [1], so we could assume it is usable (we basically do that already, see guestfs_impl_get_tmpdir). [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html > Should we provide an API to read the sockname, analogous to > guestfs_get_tmpdir and guestfs_get_cachedir? This makes me think that we could actually move all the sockets (regardless of the length of tmpdir) to a new sockdir, and expose that as read-only API. > Should we use /run or /dev/shm instead? I would say, not /run/user > because systemd doesn't reliably create it, unfortunately, but maybe > somewhere else in /run would be acceptable. Theoretically /run/user/$UID is what systemd sets as $XDG_RUNTIME_DIR, which is described in the XDG basedir spec [2]. We could try to use it if set, creating a new guestfs-sockXXXXXX temporary directory. [2] http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html > How does libvirt handle socket paths? Does it put them in /run, and > can we emulate its behaviour? It uses $XDG_RUNTIME_DIR if set, falling back to ~/.cache ($XDG_CACHE_HOME actually), creating the directories (mkdir -p, basically). > Are there implications for testing? [When running tests, the ./run > script sets TMPDIR to point to /path/to/libguestfs/tmp. Minot nitpick: "run" does not set $TMPDIR, but $LIBGUESTFS_TMPDIR, so temporary stuff of anything non-libguestfs are still outside of libguestfs' tmpdir. Aside the above: the appliance will still be in the same possible places (including where "run" points tmpdir to), we need to find a better place for sockets only (whose paths have a limitation on the length). -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
