[Libguestfs] [PATCH 6/6] launch: avoid too long paths for sockets

[Pino Toscano]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20160201/03829e13/attachment.sig>