Hi! > >> Oh, you mean that #!/usr/bin/make -f would turn into /usr/bin/make > >> /dev/fd/3? That could be interesting, although I can imagine it > >> breaking things, especially if /dev/fd/3 isn't set up like that, e.g. > >> early in boot. > > > > Sigh... What I mean is that fexecve(fd, ...) would have to put _something_ > > into argv when it execs the interpreter of #! file. Simply because the > > interpreter (which can be anything whatsoever) has no fscking idea what > > to do with some descriptor it has before execve(). Hell, it doesn't have > > any idea *which* descriptor had it been. > > > > You need to put some pathname that would yield your script upon open(2). > > If you bothered to read those patches, you'd see that they do supply > > one, generating it with d_path(). Which isn't particulary reliable. > > > > I'm not sure there's any point putting any of that in the kernel - if > > you *do* have that pathname, you can just pass it. > > Hmm. > > This issue certainly makes fexecve or execveat less attractive, at > least in cases where d_path won't work. > > On the other hand, if you want to run a static binary on a cloexec fd > (or, for that matter, a dynamic binary if you trust the interpreter to > close the extra copy of the fd it gets) in a namespace or chroot where > the binary is invisible, then you need kernel help. > > It's too bad that script interpreters don't have a mechanism to open > their scripts by fd. Every interpretter depends on /dev/zero... so what about having /dev/script_im_running? Standard character device, contains whatever script it should contain... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
