Re: luajit fdopen luaposix

[William Ahern <william@...>]

On Thu, Nov 26, 2015 at 11:44:44AM +0100, Mike Belopuhov wrote:
> On Wed, Nov 25, 2015 at 15:52 -0800, William Ahern wrote:
> > On Wed, Nov 25, 2015 at 12:54:25PM +0100, Mike Belopuhov wrote:
<snip>
> > Some comments:
> > 
> > 1) POSIX fdopen takes a mode argument. You're only partially implementing
> > the interface by dup'ing the descriptor over the pre-existing descriptor.
> > 
> > 2) In jailed environments there may be no /tmp or even any writable
> > directories at all.
> >
> 
> All good points, indeed.

I forgot perhaps the most important difference: the descriptor number is
different.

> > It attempts to open "." or "/dev/null" to get a blessed LuaJIT object using
> > io.open. Visibility or read permissions aren't guaranteed, but more likely
> > to work in a jailed environment. Then it replaces that FILE handle
> > completely with a newly fdopen'd handle rather than dup'ing over the
> > descriptor.
> >
> 
> On our platform (OpenBSD) opening directories read-write (with open(2),
> fopen(3) or io.open for that matter) doesn't work and generally speaking
> would be a wrong thing to do anyways since there's no specified interface
> for modifying directory entries via the write(2) system call. "/dev/null"
> is also generally not available in [proper] chroot environments, however
> it can be created manually of course.

I use and test lunix regularly on OpenBSD. :) Both open(".", O_RDONLY) and
fopen(".", "r") work. (Just confirmed but I usually test these things on all
my systems before relying on them.) That's all that matters because we only
need to create a LuaJIT file object; the FILE handle and it's associated
descriptor will be replaced with the FILE handle from fdopen.

> > [1] lunix is thread-safe[2], provides common extensions not defined by POSIX
> > (with custom implementations if needed to make them "portable"), and is
> > regularly tested on many non-Linux platforms--AIX, OS X, Solaris, and
> > several different BSDs.
> > 
> > [2] At least as much as possible. The LuaJIT hack, for example, doesn't
> > permit properly emulating the "x" (O_CLOEXEC) flag to fdopen, which could
> > allow the temporary descriptor to be unintentionally inherited if another
> > thread calls forks at the same time. Although I just realized that LuaJIT
> > doesn't appear to check the contents of mode, so I should probably try to
> > pass it through. (And maybe also add a runtime check to see if the x flag is
> > supported by libc.)
> > 
> 
> The lack of explicit CLOEXEC handling can be circumvented by calling
> posix.fcntl with a F_SETFD and FD_CLOEXEC. This is a POSIX interface:
>  http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html
> and is implemented by luaposix since Jul 4, 2015.

That still leaves the race, though.

Thread 1: open
Thread 2: fork
Thread 1: fcntl+FD_CLOEXEC

I do emulate O_CLOEXEC and "x" by setting FD_CLOEXEC directly. Although at
this point I don't think any of the popular Unix systems lack support for
O_CLOEXEC. O_CLOEXEC is also required by the latest POSIX standard, though
the lastest isn't well supported overall, Solaris being the furthest behind.
The only headache, IIRC, is AIX, which puts O_CLOEXEC in the high bits of a
64-bit mode_t.