tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: more fexecve questions



On 10.09.2019 17:04, Taylor R Campbell wrote:
>> Date: Tue, 10 Sep 2019 10:52:47 -0400
>> From: christos%zoulas.com@localhost (Christos Zoulas)
>>
>> 1. Looks like FreeBSD (and my initial posting) leaves the file descriptor
>>    of the executable open in the process's image. The Linux man page says
>>    to set close-on-exec if you don't want it to be passed to the child
>>    process. Which behavior do you prefer? To have fexecve close the fd
>>    automatically or to leave it up to the caller? It seems less magical
>>    to leave it to the caller, but it also requires action from the caller.
> 
> I don't see why fexec should behave differently from exec in the
> decision of which fds stay open.  We already have a mechanism to
> request any other fd be closed on exec.
> 

Am I reading it correctly that FreeBSD and Linux behave the same way? By
default the fd is open, unless close-on-exec set?

I would keep the same behavior and leave it to caller.

>> 2. I am setting the path of the executable to "/" and p_comm to "*fexecve*".
>>    I could also do a reverse lookup and set them to the path of the binary,
>>    I found and default to "/" and "*fexecve*" if that's not found. I know
>>    people don't like those reverse lookups because of the vnode cache
>>    issues...
> 
> Can we just cache these when the file descriptor is opened with
> O_EXEC?
> 
> The cache could become stale if the executable or any parent directory
> is moved or deleted.  But they could become stale after exec too for
> the same reason.
> 

O_EXEC should be tunable in runtime, with:

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);

It would be nice to get support for: F_GETPATH, for every file
descriptor with associated file path.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index