Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

[Rich Felker]

On Fri, Jan 09, 2015 at 10:33:00PM +0000, Al Viro wrote:
> On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
> > > Back then the procfs-free environments had been pushed as a serious argument
> > > in favour of merging the damn thing.  Now you guys turn around and say that
> > > we not only need procfs mounted, we need a yet-to-be-added kludge in there
> > > to cope with the actual intended uses.
> > 
> > Reverting does not fix the problem. There is no way to make fexecve
> > work for scripts without kernel support, and the needed kernel support
> > without fexecve would be even nastier, since handling of /proc/self/fd
> > magic-symlinks would need to be special-cased. The added fexecveat
> > syscall supports fully /proc-less operation for non-scripts.
> 
> Oh, yes it does.  It's not *our* problem if it's out of tree and not
> a part of ABI.  That way if you need it, *you* get to come up with clean
> implementation.  If it's in-tree you get leverage to push ugly kludges
> further in.  And frankly, I don't trust you to abstain from using that
> leverage in rather nasty ways.
> 
> Out of curiosity, how would you expect that "open only once" to work?
> All reliable variants I see are beyond sick...

Here's a very simple way it could work -- it could put the O_PATH fd
on a previously-unused fd number, and put a special flag on the fd,
like FD_CLOEXEC, but that causes the kernel to close it whenever it's
opened. The pathname passed could then simply be /dev/fd/%d or
/proc/self/fd/%d, and although this is presently dependent on /proc
being mounted, virtual /dev/fd/* could someday be something completely
independent of procfs. The kernel keeps all the freedom to choose how
to pass the name to the interpreter. I'm not proposing any kernel
API/ABI lock-in and I'm with you in opposing such lock-in.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/