>> How does fexecve() make anything possible here that wasn't possible
>> before? It seems to me that updating .so libraries has always
>> carried this risk, so I must be missing something.
> Without fexecve() it's at least theoretically possible to remove t
gt; (3) Setugid processes should be prohibited, or at least setugid
> > dynamically-linked processes, because otherwise there's a window
> > where a live update of a library might be used to run the old binary
> > with a new set of libraries.
>
> How does fexecve() m
> On Sep 15, 2019, at 1:40 AM, m...@netbsd.org wrote:
>
> Please add a comment explaining that this is for pathnames we can't
> resolve in chroots.
Done. It is not for chroots though It is for when we can't resolve vnode to
name.
>
> segvguard and veriexec ony use the name for printing
Please add a comment explaining that this is for pathnames we can't
resolve in chroots.
> @@ -224,9 +225,11 @@ elf_populate_auxv(struct lwp *l, struct
> a->a_v = l->l_proc->p_stackbase;
> a++;
>
> - execname = a;
> - a->a_type = AT_SUN_EXECNAM
goto clrflg;
- data->ed_pathstring = pathbuf_stringcopy_get(data->ed_pathbuf);
- data->ed_resolvedpathbuf = PNBUF_GET();
+ if (path == NULL) {
+ data->ed_pathbuf = pathbuf_assimilate(strcpy(PNBUF_GET(), "/&q
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 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
ag to open() to obtain a file descriptor that can be passed to
>> fexecve(). That's what O_EXEC is for. Whether the receiving process
>> can successfully fexecve(2) such a file descriptor is another matter.
>> That's what the "execute permission is checked by fexecve
>> [...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
Since you can open such
^can't open such
> a file for reading or writing (except as root) you need an additional
> flag to open() to obtain a file descriptor that can be passed to
> fexecve(). That's what O_EXEC is for. Whether the rec
; 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 by fexecve(), the file description
> fd n
> 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
>
> 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.
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
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 by fexecve(), the file description
fd need not have been opened
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
> 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 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
27;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
gt;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 calle
> 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
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
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 cl
not really commenting on the proposal itself, but ..
> Let us not forget that you need a binary inside the chroot that can
> call fexecve() on a file descriptor or the ability to build such a
> binary.
this is only one buffer overflow away... ie, strength in
layers would imply you s
>> (I'd actually _like_ to see something capabilityish, in which case
>> "can use fexecve" would be a capability that could be removed, from
>> init if need be, on systems that care about this sort of thing.)
> Couldn't we have an enable/disable sysctl vari
> Date: Sun, 8 Sep 2019 14:03:03 -0400
> From: Thor Lancelot Simon
>
> On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
> >
> > Here's a simple fexecve(2) implementation. Comments?
>
> I think this is dangerous in systems which use chroot in
ly circumvented.
Isn't the command name easy to lose and/or forge already, with links if
nothng else? In any case, it seems to me this is one reason to make
fexecve() optional. (I'd actually _like_ to see something
capabilityish, in which case "can use fexecve" would be a cap
Isn't the command name easy to lose and/or forge already, with links if
nothng else? In any case, it seems to me this is one reason to make
fexecve() optional. (I'd actually _like_ to see something
capabilityish, in which case "can use fexecve" would be a capability
that cou
Christos Zoulas wrote:
> - We can completely dissallow fexecve in chrooted environments.
Full disk encryption (loaded with cgdroot.kmod) requires a complete
system to be chrooted.
--
Alex
> Here's a simple fexecve(2) implementation. Comments?
Strikes me as a very good thing to have optionally available.
I'd need to think a good deal more to decide whether I think it's a
reasonable thing to have enabled by default.
/~\ The ASCII
On Sun, Sep 08, 2019 at 07:27:10PM +, David Holland wrote:
> On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
> > Here's a simple fexecve(2) implementation. Comments?
>
> Two additional things come to mind besides the chroot issue:
...for large values
On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
> Here's a simple fexecve(2) implementation. Comments?
Two additional things come to mind besides the chroot issue:
(1) For consistency of permission handling, it ought to require that
the file be opened with O_EXEC, and c
23:46PM -0400, Christos Zoulas wrote:
>> >>
>> >> Here's a simple fexecve(2) implementation. Comments?
>> >
>> >I think this is dangerous in systems which use chroot into filesystems
>> >mounted noexec (or nosuid) and file-descriptor passing into t
On Sun, Sep 08, 2019 at 06:27:11PM -, Christos Zoulas wrote:
> In article <20190908180303.ga6...@panix.com>,
> Thor Lancelot Simon wrote:
> >On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
> >>
> >> Here's a simple fexecve(2) impleme
In article <20190908180303.ga6...@panix.com>,
Thor Lancelot Simon wrote:
>On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
>>
>> Here's a simple fexecve(2) implementation. Comments?
>
>I think this is dangerous in systems which use chroot into
On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote:
>
> Here's a simple fexecve(2) implementation. Comments?
I think this is dangerous in systems which use chroot into filesystems
mounted noexec (or nosuid) and file-descriptor passing into the constrained
environment t
Here's a simple fexecve(2) implementation. Comments?
christos
Index: include/unistd.h
===
RCS file: /cvsroot/src/include/unistd.h,v
retrieving revision 1.151
diff -u -p -u -r1.151 unistd.h
--- include/unistd.h18 Nov 2018
If we _are_ able to restrict fch*, we will be able to do the same with fexec*.
> this, among several other additional changes our chroot support
> has, are why netbsd chroots are a better base for security than
> other platforms chroots.
I think proposed fexecve cannot weaken NetBS
On Wed, 5 Dec 2012 20:42:32 +
David Holland wrote:
> That may be, but it's still true of file descriptors. Traditionally
> they're capabilities, and I really don't like the idea of rearranging
> that arbitrarily and inconsistently.
>
> I think to do this correctly, exec and search on file ha
> I've reread the whole thread but I don't understand how fch* and fexec*
> differ.
> As far as I can see all they cause the same sort of problems.
> So, a solution should be the same for all of them.
AFAIK (i didn't write a test), fchroot() outside of the chroot
is already disallowed by the ker
ut the fexecve (etc) set of calls,
but my message, and the "this system call" that I was referring to was
the ancient exec (or slightly more modern execve) with no 'f' in its name.
That related to the message about exec("/proc/self/fds/3", ...) not
working (for reason
On Wed, Dec 05, 2012 at 04:03:40PM -0500, Mouse wrote:
> >> * whether the name in question is within the process' current
> >> root (forbidding fchdir and fchroot otherwise).
> > Definitely.
>
> I'm actually not convinced this is so obviously a good thing.
>
> I see an analogy betwee
>> * whether the name in question is within the process' current
>>root (forbidding fchdir and fchroot otherwise).
> Definitely.
I'm actually not convinced this is so obviously a good thing.
I see an analogy between root directories and UIDs. We have chroot(),
and we have setuid() -
On Wed, Dec 05, 2012 at 08:39:55AM -0500, Thor Lancelot Simon wrote:
> I also think we need to check, for all the fch*, fexec* syscalls:
>
> * permissions both retained from the file's open and at the time
>of use
I don't think this is necessary, any more than it is for read and
On Wed, Dec 05, 2012 at 01:08:14PM -0500, Mouse wrote:
> > This system call embodies a fairly fundamental shift away from the
> > Unix model that object permissions are checked when you get a handle
> > to an object -- not when you use that handle.
>
> Actually, I think that's true only of fi
chroot in rc.d.
>
> On the other hand if we generalize improvements of fchdir(2) and fchroot(2)
> (I mean EPERM if the current working directory is not at or under the new
> root directory), that is reimplement them with a help of kauth(9) we
> will be able
> to do the same for fexecve(2).
>
> All in all, unless I miss something I don't see serious contradictions
> between chroot and kexecve.
>
> This system call embodies a fairly fundamental shift away from the
> Unix model that object permissions are checked when you get a handle
> to an object -- not when you use that handle.
Actually, I think that's true only of file descriptors. I'm having
trouble thinking of any other case where p
under the new
>> root directory), that is reimplement them with a help of kauth(9) we
>> will be able to do the same for fexecve(2).
>
> I don't think that's necessarily the case (we've discussed why earlier
> in this terribly fragmented thread).
I've rer
kauth(9) we
> will be able to do the same for fexecve(2).
I don't think that's necessarily the case (we've discussed why earlier
in this terribly fragmented thread).
Thor
w easely daemons can be configured for running inside chroot in rc.d.
On the other hand if we generalize improvements of fchdir(2) and fchroot(2)
(I mean EPERM if the current working directory is not at or under the new
root directory), that is reimplement them with a help of kauth(9) we
will be a
.
The symlink case does not involve the fundamental shift away
from the Unix model of checking permissions when you look up
the name that this does.
2) In the symlink case, it is not possible for the question of the
file's name to be unanswer
Date:Wed, 5 Dec 2012 03:02:09 +
From:"Roland C. Dowdeswell"
Message-ID: <20121205030209.gv1...@mournblade.imrryr.org>
| Let's not lose sight of the fact that chroot can most certainly
| compromise security if used improperly
Yes, of course, there can be secur
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote:
>
> Even chroot isn't a problem, unless you're tempted to view it as some
> kind of security mechanism. It really isn't - it is just namespace
> modification. Sure, by modifying the filesystem namespace a bunch
> of simple security at
On Tue, 4 Dec 2012 15:30:36 +
David Holland wrote:
> On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote:
> > > The descriptor is probably already "closed on exec" before the
> > > syscall tries to use it.
> >
> > Nope. That happens later. I was looking through this code
> > yest
Date:Tue, 4 Dec 2012 15:44:47 +0300
From:Alan Barrett
Message-ID: <20121204124447.gf8...@apb-laptoy.apb.alt.za>
| >>> The fexecve function could be implemented entirely in libc,
| >>> via execve(2) on a file name of the form "/proc/se
On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote:
> > The descriptor is probably already "closed on exec" before the syscall
> > tries to use it.
>
> Nope. That happens later. I was looking through this code yesterday as
> the topic interests me. The namei lookup happens pretty earl
On Tue, 4 Dec 2012 08:49:17 + (UTC)
mlel...@serpens.de (Michael van Elst) wrote:
> The descriptor is probably already "closed on exec" before the syscall
> tries to use it.
Nope. That happens later. I was looking through this code yesterday as
the topic interests me. The namei lookup happens
The fexecve function could be implemented entirely in libc,
via execve(2) on a file name of the form "/proc/self/fd/".
Any security concerns around fexecve() also apply to exec of
/proc/self/fd/.
I gave a try to this approach. There is an unexpected issue:
The descriptor is probab
m...@netbsd.org (Emmanuel Dreyfus) writes:
>Alan Barrett wrote:
>> The fexecve function could be implemented entirely in libc,
>> via execve(2) on a file name of the form "/proc/self/fd/".
>> Any security concerns around fexecve() also apply to exec of
>&
Alan Barrett wrote:
> The fexecve function could be implemented entirely in libc,
> via execve(2) on a file name of the form "/proc/self/fd/".
> Any security concerns around fexecve() also apply to exec of
> /proc/self/fd/.
I gave a try to this approach. There is an u
On Wed, Nov 28, 2012 at 03:12:36PM +, David Holland wrote:
> On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
> > If necessary, the open(2) syscall could be versioned so that
> > O_RDONLY is no longer defined as zero.
>
> This seems possibly worth doing to avoid all the ann
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
> If necessary, the open(2) syscall could be versioned so that
> O_RDONLY is no longer defined as zero.
This seems possibly worth doing to avoid all the annoyance with
FREAD/FWRITE vs. O_RDONLY/O_WRONLY, but I really don't see how it'
fficient to use
certain "methods" of the descriptor---for example, to fexecve() the
descriptor---but I think that is ok, because B's entire purpose may be
to send the descriptor to a third process that can use the descriptor.
Dave
--
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981
On Mon, Nov 26, 2012 at 10:18:42AM +0100, Martin Husemann wrote:
> Does anyone know of a setup that uses a process outside of a chroot doing
> descriptor passing to a chrooted process?
Yes. I mentioned some earlier in this discussion, before the thread
jumps.
I don't have time to write it up ag
On Mon, Nov 26, 2012 at 09:01:10AM +, David Laight wrote:
> O_SEARCH0x4
> O_EXEC 0x8
The standard notes that O_EXEC and O_SEARCH are never used together
and therefore may be set to the same binary value.
--
Emmanuel Dreyfus
m...@netbsd.org
Does anyone know of a setup that uses a process outside of a chroot doing
descriptor passing to a chrooted process?
I wonder if we should disallow that completely (i.e. fail the anxiliary
data send if sender and recipient have different p_cwdi->cwdi_rdir)?
Martin
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
>
> If necessary, the open(2) syscall could be versioned so that
> O_RDONLY is no longer defined as zero.
Actually we could redefine (say)
O_RDONLY0x1
O_WRONLY0x2
O_RDWR (O_RDON
On Sun, Nov 25, 2012 at 10:58:01PM -0500, Thor Lancelot Simon wrote:
> > Yes, I agree there is no security hazard introduced: if help from a
> > process outside the chroot is assumed, there are already many ways to
> > cirumvent chroot security.
>
> And I strongly disagree. We've discussed this at
On Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote:
> David Laight wrote:
>
> > Given a chrooted process would need a helping process outside the
> > chroot (to pass it the fd), why is allowing the chrooted proccess to
> > exec something any different from it arranging to get the he
David Laight wrote:
> Given a chrooted process would need a helping process outside the
> chroot (to pass it the fd), why is allowing the chrooted proccess to
> exec something any different from it arranging to get the helper
> to do it?
Yes, I agree there is no security hazard introduced: if he
On Sun, Nov 25, 2012 at 11:47:14PM +, David Laight wrote:
>
> On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote:
> > >
> > >> Does everyone agrees on this interpretation? If we do, next steps are
> > >> - describe threats this introduce to chrooted processes
>
> Given a chrooted
On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote:
> >
> >> Does everyone agrees on this interpretation? If we do, next steps are
> >> - describe threats this introduce to chrooted processes
Given a chrooted process would need a helping process outside the
chroot (to pass it the fd),
The NetBSD core group has considered adding the
fexecve(2) or fexecve(3) syscall or function, and adding
new O_EXEC and O_SEARCH open(2) flags.
These new features may be useful, but their security properties
are not well understood. The core group is of the opinion that
these new features
>>> O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR
>> - simply don't include this poorly-designed functionality in NetBSD.
> Unless you want to change O_RDONLY to be non-zero and version all the
> syscalls that use it :-)
I don't see any need to do that, unless they were crazy e
In article <20121125152520.ga17...@panix.com>,
Thor Lancelot Simon wrote:
>On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote:
>> Let's try to move forward, and I will start will a sum up of what I
>> understand from the standard. It would be nice if we could at least
>> reach conse
On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote:
> Let's try to move forward, and I will start will a sum up of what I
> understand from the standard. It would be nice if we could at least
> reach consensus on standard interpretation.
I think your interpretation of the standard is
Let's try to move forward, and I will start will a sum up of what I
understand from the standard. It would be nice if we could at least
reach consensus on standard interpretation.
We have two operations:
- Open stage: openat() of a file
- Exec stage: fexecve() using the file descriptor obt
On Apr 11, 9:48am, Emmanuel Dreyfus wrote:
} On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
} > No, Emmanuel is right: "[...] use the O_EXEC flag when opening fd. In
} > this case, the application will not be able to perform a checksum test
} > since it will not be able to read the co
David Laight wrote:
> Given the comments later about O_SEARCH | O_RDONLY not being distinguishable
> from O_SEARCH
The satandard forbids O_SEARCH | O_RDONLY anyway, so it should not be a
problem.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Mon, Nov 19, 2012 at 11:25:07AM -0500, Thor Lancelot Simon wrote:
> On Mon, Nov 19, 2012 at 03:13:02PM +, Emmanuel Dreyfus wrote:
> > On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
> > > No, Emmanuel is right: "[...] use the O_EXEC flag when opening fd. In
> > > this case, the a
On Mon, Nov 19, 2012 at 03:13:02PM +, Emmanuel Dreyfus wrote:
> On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
> > No, Emmanuel is right: "[...] use the O_EXEC flag when opening fd. In
> > this case, the application will not be able to perform a checksum test
> > since it will not
On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
> No, Emmanuel is right: "[...] use the O_EXEC flag when opening fd. In
> this case, the application will not be able to perform a checksum test
> since it will not be able to read the contents of the file." You can
> open with --x but (co
On Mon, 19 Nov 2012 08:38:11 +
David Laight wrote:
> On Mon, Nov 19, 2012 at 08:08:58AM +, Emmanuel Dreyfus wrote:
> >
> > If you have r-x permission, you open with O_RDONLY and you do not
> > need O_SEARCH/O_EXEC.
> >
> > If you have --x permission, you open with O_SEARCH/O_EXEC
>
>
> If you don't have read rights you can open with O_EXEC instead, and
> you can't read the file you just opened; it merely provides a
> mechanism to pointlessly use fexecve.
I disagree that it's pointless.
You can still check that, for example, it's the same dev/inum
re is how I understand it for an openat/mkdirat sequence:
> - openat() without O_SEARCH, get a search check at mkdirat() time
> - openat() with O_SEARCH, mkdirat() performs no search check.
>
> and for openat/fexecve:
> - openat() without O_SEXEC, get a execute check at fexecve() t
On Mon, Nov 19, 2012 at 05:23:07AM +, David Holland wrote:
> On Sun, Nov 18, 2012 at 06:51:51PM +, David Holland wrote:
> > > > This appears to contradict either the description of O_EXEC in the
> > > > standard, or the standard's rati
irat() time
- openat() with O_SEARCH, mkdirat() performs no search check.
and for openat/fexecve:
- openat() without O_SEXEC, get a execute check at fexecve() time
- openat() with O_EXEC, fexecve() performs no exec check.
If you have r-x permission, you open with O_RDONLY and you do not need
O_SEA
scriptor.
Incredibly, the spec defines the illogical behaviour: “Since execute
permission is checked by fexecve(), the file description fd need not
have been opened with the O_EXEC flag. However, if the file to be
executed denies read and write permission for the process preparing to
do the exec, th
On Sun, Nov 18, 2012 at 06:51:51PM +, David Holland wrote:
> > > This appears to contradict either the description of O_EXEC in the
> > > standard, or the standard's rationale for adding fexecve(). The
> > > standard says O_EXEC causes the fil
need to be defined as 3 so that O_ACCMODE will work
properly. O_SEARCH would also need to be defined as an alias of O_EXEC (I
don't think the current definition we use is correct).
Given that, you can't open a file for read & exec, just either read or just
exec. So how would verific
On Sun, 18 Nov 2012 14:31:29 -0500
Thor Lancelot Simon wrote:
> On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote:
> > On Sat, 17 Nov 2012 21:45:02 +
> > David Laight wrote:
> >
> > > You don't need the executable image inside the chroot.
> >
> > I don't believe that's intended to
On Sun, 18 Nov 2012 18:16:00 +
David Holland wrote:
> On Sat, Nov 17, 2012 at 06:42:50PM -0500, Thor Lancelot Simon wrote:
> >
> > Further, requiring O_EXEC would seem to directly contravene the
> > standard's language about fexecve()'s behavior.
>
&g
On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote:
> On Sat, 17 Nov 2012 21:45:02 +
> David Laight wrote:
>
> > On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
> > >
> > > What does this gain over passing a filename around? (NB. I'm not
> > > claiming that's an entirely
On Sat, 17 Nov 2012 21:45:02 +
David Laight wrote:
> On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
> >
> > What does this gain over passing a filename around? (NB. I'm not
> > claiming that's an entirely safe model either, but it's already
> > possible).
>
> You don't need the
On Sun, Nov 18, 2012 at 07:42:43PM +0100, Emmanuel Dreyfus wrote:
> > The standard is clearly wrong on a number of points and doesn't match
> > the historical design and behavior of Unix. Let's either implement
> > something correct, or not implement it at all.
>
> Do you have something corre
On Sun, Nov 18, 2012 at 06:16:00PM +, David Holland wrote:
> > This appears to contradict either the description of O_EXEC in the
> > standard, or the standard's rationale for adding fexecve(). The
> > standard says O_EXEC causes the file to be open for execution
David Holland wrote:
> The standard is clearly wrong on a number of points and doesn't match
> the historical design and behavior of Unix. Let's either implement
> something correct, or not implement it at all.
Do you have something correct to sugest?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/
uting code. Here is a proposal for chrooted processes:
> > 1) if current process and executed vnode have different roots, then
> > fexecve() fails
> > 2) if the fd was not open with O_EXEC, fexecve() fails.
>
> This appears to contradict either the description of O_EX
Rhialto wrote:
> > The definition is really vague. As I understand, nothing forbids opening
> > O_EXEC|O_RDWR.
> Applications shall specify exactly one of the first five values (file
> access modes) below in the value of oflag:
Right, I missed that point.
--
Emmanuel Dreyfus
http://hcpnet.
On Sat, Nov 17, 2012 at 11:48:20AM +0100, Emmanuel Dreyfus wrote:
> Here is an attempt to address what was said about implementing fexecve()
>
> fexecve() checks that the vnode underlying the fd :
> - is of type VREG
> - grants execution right
>
> O_EXEC cause open()/op
1 - 100 of 154 matches
Mail list logo
