lkml.org 
[lkml]   [2015]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
    On Fri, Jan 09, 2015 at 03:59:26PM -0500, Rich Felker wrote:

    > > For fsck sake, folks, if you have bloody /proc, you don't need that shite
    > > at all! Just do execve on /proc/self/fd/n, and be done with that.
    > >
    > > The sole excuse for merging that thing in the first place had been
    > > "would anybody think of children^Wsclerotic^Whardened environments
    > > where they have no /proc at all".
    >
    > That doesn't work. With O_CLOEXEC, /proc/self/fd/n is already gone at
    > the time the interpreter runs, whether you're using fexecveat or
    > execve with "/proc/self/fd/n" to implement POSIX fexecve(). That's the
    > problem. This breaks the intended idiom for fexecve.

    Just what will your magical symlink do in case when the file is opened,
    unlinked and marked O_CLOEXEC? When should actual freeing of disk blocks,
    etc. happen? And no, you can't assume that interpreter will open the
    damn thing even once - there's nothing to oblige it to do so.

    Al, more and more tempted to ask reverting the whole thing - this hardcoded
    /dev/fd/... (in fs/exec.c, no less) is disgraceful enough, but threats of
    even more revolting kludges in the name of "intended idiom for fexecve"...


    \
     
     \ /
      Last update: 2015-01-09 22:21    [W:4.797 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site