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