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
auto
> Date: Tue, 10 Sep 2019 10:52:47 -0400
> From: chris...@zoulas.com (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 passe
Hello
I'm trying to build a evbarm kernel with
options SLJIT
options BPFJIT
and it fails with:
/local/armandeche1/netbsd-9/src/sys/net/bpfjit.c:73:10: fatal error:
sljitLir.h: No such file or directory
#include
^~~~
The file is in sys/external/bsd/sljit/dist/s
> 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.
For designed-for-NetBSD code, callers already need changing to use
fexecve at all, so I
Manuel Bouyer wrote:
>I'm trying to build a evbarm kernel with
>options SLJIT
>options BPFJIT
Are you building a 32 or 64-bit kernel ?
On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
>
> Manuel Bouyer wrote:
> >I'm trying to build a evbarm kernel with
> >options SLJIT
> >options BPFJIT
>
> Are you building a 32 or 64-bit kernel ?
32-bits.
--
Manuel Bouyer
NetBSD: 26 ans d'experience f
On Tue, Sep 10, 2019 at 05:43:51PM +0200, Manuel Bouyer wrote:
> On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
> >
> > Manuel Bouyer wrote:
> > >I'm trying to build a evbarm kernel with
> > >options SLJIT
> > >options BPFJIT
> >
> > Are you building a 32 or 6
Manuel Bouyer wrote:
>On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
>>
>> Manuel Bouyer wrote:
>> >I'm trying to build a evbarm kernel with
>> >options SLJIT
>> >options BPFJIT
>>
>> Are you building a 32 or 64-bit kernel ?
>
>32-bits.
Try this:
Index: f
In article <20190910150418.becab60...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>> Date: Tue, 10 Sep 2019 10:52:47 -0400
>> From: chris...@zoulas.com (Christos Zoulas)
>>
>> 1. Looks like FreeBSD (and my initial posting) leaves the file descriptor
>>of the executable open in the process'
On 10.09.2019 17:04, Taylor R Campbell wrote:
>> Date: Tue, 10 Sep 2019 10:52:47 -0400
>> From: chris...@zoulas.com (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
On Tue, Sep 10, 2019 at 05:01:43PM +0100, Robert Swindells wrote:
>
> Manuel Bouyer wrote:
> >On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
> >>
> >> Manuel Bouyer wrote:
> >> >I'm trying to build a evbarm kernel with
> >> >options SLJIT
> >> >options BPFJIT
On Tue, Sep 10, 2019 at 06:11:55PM +0200, Kamil Rytarowski wrote:
> O_EXEC should be tunable in runtime, with:
>
> fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);
Why? You can't do that with O_WRITE.
--
David A. Holland
dholl...@netbsd.org
> Date: Tue, 10 Sep 2019 16:03:23 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <20190910150418.becab60...@jupiter.mumble.net>,
> Taylor R Campbell wrote:
> >Can we just cache these when the file descriptor is opened with
> >O_EXEC?
> >
> >The cache could become stale
On Sun, Sep 08, 2019 at 09:53:50PM +, Taylor R Campbell wrote:
> > What can we do about that?
>
> It sounds like you're positing:
>
> - there is a chrooted process A
> - there is a colluding process B outside the chroot
> - they share a socket
> - B can open setuid executables and sen
On 10.09.2019 18:21, David Holland wrote:
> On Tue, Sep 10, 2019 at 06:11:55PM +0200, Kamil Rytarowski wrote:
> > O_EXEC should be tunable in runtime, with:
> >
> > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);
>
> Why? You can't do that with O_WRITE.
>
I don't know. I was looking for a c
In article <20190910162429.a525e60...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>>
>> I guess we could, since the problem is that if the filename is greater than
>> NCHNAMLEN, they will not be cached. But I am not familiar enough with the
>> cache to make the changes required.
>
>I don't mea
> On Sep 10, 2019, at 9:26 PM, Christos Zoulas wrote:
>
> I think is time to ditch NCHNAMLEN like FreeBSD did, and rely on
> the namei cache for reverse mappings. This way we can also implement
> F_GETPATH which Kamil seems to keep bringing up :-).
FWIW, XNU's VFS uses this approach as well.
> On Sep 10, 2019, at 8:31 PM, Kamil Rytarowski wrote:
>
> I don't know. I was looking for a corner case when we would skip this
> cache of O_EXEC on fexecve().
>
> POSIX states:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
>
> 'Since execute permission is checked
On Tue, Sep 10, 2019 at 07:31:47PM +0200, Kamil Rytarowski wrote:
> On 10.09.2019 18:21, David Holland wrote:
> > > O_EXEC should be tunable in runtime, with:
> > > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);
> > Why? You can't do that with O_WRITE.
> I don't know. I was looking for a corne
On Tue, Sep 10, 2019 at 09:45:50PM +0200, Christoph Badura wrote:
> This is to catch the following case(s): The file might have the
> following permissions "--x--x--x" (or equivalent where the open()ing
> process doesn't have read or write permission). Since you can open such
>> [...O_EXEC...]
It sounds to me as though O_EXEC would be more honestly spelled
something more like O_NOACCESS.
It would also be useful to obtain a descriptor on a search-only
directory for fchdir() purposes, which was the motivation that led me
to add O_NOACCESS to my own systems.
/~\ The ASC
Comments?
Thanks,
christos
Index: sys/namei.h
===
RCS file: /cvsroot/src/sys/sys/namei.h,v
retrieving revision 1.98
diff -u -p -u -r1.98 namei.h
--- sys/namei.h 3 Jun 2019 06:05:39 - 1.98
+++ sys/namei.h 10 Sep 2019 23:20:
In article <20190910195235.gp...@irregular-apocalypse.k.bsd.de>,
Christoph Badura wrote:
>On Tue, Sep 10, 2019 at 09:45:50PM +0200, Christoph Badura wrote:
>> This is to catch the following case(s): The file might have the
>> following permissions "--x--x--x" (or equivalent where the open()ing
>>
> On Sep 11, 2019, at 4:37 AM, Christos Zoulas wrote:
>
> The implementation I posted requires O_EXEC because this is the only way
> to set FEXEC which is part of the check_exec() tests. Of course we can
> elide this test and not require it in the fd case. It just seems nicely
> symmetric to me
> On Sep 11, 2019, at 2:23 AM, Christos Zoulas wrote:
>
> Comments?
This looks good, and I think it would be fine for it to go in now. However, I
think we should probably instrument how many duplicate names may end up in the
name cache over the course of "normal" operation (insert "standar
On Wed, Sep 11, 2019 at 06:34:11AM +0300, Jason Thorpe wrote:
> > The implementation I posted requires O_EXEC because this is the only way
> > to set FEXEC which is part of the check_exec() tests. Of course we can
> > elide this test and not require it in the fd case. It just seems nicely
> > s
On Wed, Sep 11, 2019 at 06:49:05AM +0300, Jason Thorpe wrote:
> > On Sep 11, 2019, at 2:23 AM, Christos Zoulas wrote:
> >
> > Comments?
>
> This looks good, and I think it would be fine for it to go in now.
> However, I think we should probably instrument how many duplicate
> names may en
> On Sep 11, 2019, at 8:18 AM, David Holland wrote:
>
> I'm confused; nothing in there should lead to duplicate entries...
Duplicate names != duplicate entries.
Consider the case:
bin/CVS
bin/cat/CVS
.
.
.
bin/sh/CVS
.
.
.
Distinct vnodes, with distinct parents, all having the same name.
A
28 matches
Mail list logo
