On Mon, Jan 12, 2015 at 11:33:49AM +, David Drysdale wrote:
> On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker wrote:
> > On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> >> Rich Felker writes:
> >>
> >> > I'm not proposing code because I'm a libc developer not a kernel
> >> >
On Fri, Jan 9, 2015 at 9:50 PM, Al Viro wrote:
> On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
>
>> The "magic open-once magic symlink" approach is really the cleanest
>> solution I can find. In the case where the interpreter does not open
>> the script, nothing terribly bad happens
On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker wrote:
> On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
>> Rich Felker writes:
>>
>> > I'm not proposing code because I'm a libc developer not a kernel
>> > developer. I know what's needed for userspace to provide a conforming
>> >
On Sat, Jan 10, 2015 at 08:09:10PM -0600, Eric W. Biederman wrote:
> In implementation /proc/self/exe is a named rather than a numbered file
> descriptor. Essentially when loading an elf executable the file
> descriptor is duped to the name /proc/self/exe. The implementation
> otherwise is the sa
Rich Felker writes:
> On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
>> Rich Felker writes:
>>
>> > On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
>>
>> >> Except that if your interpreter does stat(2) (or access(2), or
>> >> getxattr(2),
>> >> etc.) before bother
On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
>
> >> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
> >> etc.) before bothering with open(2), you'll get screwed.
Rich Felker writes:
> On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
>> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
>> etc.) before bothering with open(2), you'll get screwed.
>
> Yes, but I think that would be very bad interpreter design.
> stat/getxatt
On Sat, Jan 10, 2015 at 09:27:46AM +0100, Michael Kerrisk (man-pages) wrote:
> On 01/09/2015 06:46 PM, David Drysdale wrote:
> > On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker wrote:
> >> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages)
> >> wrote:
> >>> On 11/24/2014 12:53 PM,
On 01/09/2015 06:46 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker wrote:
>> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>>> On 11/24/2014 12:53 PM, David Drysdale wrote:
Signed-off-by: David Drysdale
---
man2/execveat.2 |
On 01/09/2015 07:02 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 3:47 PM, Michael Kerrisk (man-pages)
> wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>>> Signed-off-by: David Drysdale
>>> ---
>>> man2/execveat.2 | 153
>>>
On 01/09/2015 06:46 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker wrote:
>> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>>> On 11/24/2014 12:53 PM, David Drysdale wrote:
Signed-off-by: David Drysdale
---
man2/execveat.2 |
On 01/09/2015 05:13 PM, Rich Felker wrote:
> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>>> Signed-off-by: David Drysdale
>>> ---
>>> man2/execveat.2 | 153
>>> +
On 01/09/2015 11:13 PM, Eric W. Biederman wrote:
> Rich Felker writes:
>
>> On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
>
>> The "magic open-once magic symlink" approach is really the cleanest
>> solution I can find. In the case where the interpreter does not open
>> the script, not
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > > _After_ the traversal it's too late to do this sort of thing - after all,
> > > how do you tell if your current position had been set by the traversal of
> > > your symlink
On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > _After_ the traversal it's too late to do this sort of thing - after all,
> > how do you tell if your current position had been set by the traversal of
> > your symlink or that of any normal /proc/self/fd/?
>
> Thanks for clarifying
On Sat, Jan 10, 2015 at 03:03:00AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
> > On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
> >
> > > I'm not sure where you're disagreeing with me. open of procfs symlinks
> > > does not resolve the symlink a
On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
>
> > I'm not sure where you're disagreeing with me. open of procfs symlinks
> > does not resolve the symlink and open the resulting pathname. They are
> > "magic symlinks" which
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > I'm not proposing code because I'm a libc developer not a kernel
> > developer. I know what's needed for userspace to provide a conforming
> > fexecve to applications, not how to implement that on the k
Rich Felker writes:
> I'm not proposing code because I'm a libc developer not a kernel
> developer. I know what's needed for userspace to provide a conforming
> fexecve to applications, not how to implement that on the kernel side,
> although I'm trying to provide constructive ideas. The hostilit
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
> I think that, if we really want to support clean fexecve on O_CLOEXEC
> scripts some day, the right way to do it is to fix the script
> interface for real. Have a special flag in the headers of script
> interpreters that support a
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker wrote:
> > On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
> >> On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
> >>
> >> > Here's a very simple way it could work --
On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
> I'm not sure where you're disagreeing with me. open of procfs symlinks
> does not resolve the symlink and open the resulting pathname. They are
> "magic symlinks" which are bound to the inode of the open file. I
> don't see why this ac
On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker wrote:
> On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
>> On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
>>
>> > Here's a very simple way it could work -- it could put the O_PATH fd
>> > on a previously-unused fd number, and put
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
>
> > Here's a very simple way it could work -- it could put the O_PATH fd
> > on a previously-unused fd number, and put a special flag on the fd,
> > like FD_CLOEXEC, but that c
On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
> Here's a very simple way it could work -- it could put the O_PATH fd
> on a previously-unused fd number, and put a special flag on the fd,
> like FD_CLOEXEC, but that causes the kernel to close it whenever it's
> opened. The pathname p
On Fri, Jan 09, 2015 at 10:33:00PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
> > > Back then the procfs-free environments had been pushed as a serious
> > > argument
> > > in favour of merging the damn thing. Now you guys turn around and say
> > > that
On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
>
> > The "magic open-once magic symlink" approach is really the cleanest
> > solution I can find. In the case where the interpreter does not op
On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
> > Back then the procfs-free environments had been pushed as a serious argument
> > in favour of merging the damn thing. Now you guys turn around and say that
> > we not only need procfs mounted, we need a yet-to-be-added kludge in ther
On Fri, Jan 09, 2015 at 09:50:42PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
>
> > The "magic open-once magic symlink" approach is really the cleanest
> > solution I can find. In the case where the interpreter does not open
> > the script, nothing terribl
Rich Felker writes:
> On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
> The "magic open-once magic symlink" approach is really the cleanest
> solution I can find. In the case where the interpreter does not open
> the script, nothing terribly bad happens; the magic symlink just
> sticks
On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
> The "magic open-once magic symlink" approach is really the cleanest
> solution I can find. In the case where the interpreter does not open
> the script, nothing terribly bad happens; the magic symlink just
> sticks around until _exit o
On Fri, Jan 09, 2015 at 03:20:04PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
> >> On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
> >> > I think this is a case that needs to be fixed, though it's hard. The
> >
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
> 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 e
Rich Felker writes:
> On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
>> On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
>> > I think this is a case that needs to be fixed, though it's hard. The
>> > normal correct usage for fexecve is to always pass an O_CLOEXEC file
>> > d
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 a
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
> > I think this is a case that needs to be fixed, though it's hard. The
> > normal correct usage for fexecve is to always pass an O_CLOEXEC file
> > descriptor, and the caller ca
On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
> I think this is a case that needs to be fixed, though it's hard. The
> normal correct usage for fexecve is to always pass an O_CLOEXEC file
> descriptor, and the caller can't really be expected to know whether
> the file is a script or
On Fri, Jan 09, 2015 at 05:46:28PM +, David Drysdale wrote:
> > It's AT_EXECFN,
> > /proc/self/exe, and filenames shown elsewhere in /proc that may be
> > derived in odd ways.
> >
> > I would also move the text about O_CLOEXEC to a BUGS or NOTES section
> > rather than the main description. The
On Fri, Jan 9, 2015 at 3:47 PM, Michael Kerrisk (man-pages)
wrote:
> On 11/24/2014 12:53 PM, David Drysdale wrote:
>> Signed-off-by: David Drysdale
>> ---
>> man2/execveat.2 | 153
>>
>> 1 file changed, 153 insertions(+)
>> create mode 1
On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker wrote:
> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>> > Signed-off-by: David Drysdale
>> > ---
>> > man2/execveat.2 | 153
>> >
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
> On 11/24/2014 12:53 PM, David Drysdale wrote:
> > Signed-off-by: David Drysdale
> > ---
> > man2/execveat.2 | 153
> >
> > 1 file changed, 153 insertions(+)
> >
On 11/24/2014 12:53 PM, David Drysdale wrote:
> Signed-off-by: David Drysdale
> ---
> man2/execveat.2 | 153
>
> 1 file changed, 153 insertions(+)
> create mode 100644 man2/execveat.2
David,
Thanks for the very nicely prepared man page.
Signed-off-by: David Drysdale
---
man2/execveat.2 | 153
1 file changed, 153 insertions(+)
create mode 100644 man2/execveat.2
diff --git a/man2/execveat.2 b/man2/execveat.2
new file mode 100644
index ..937d79e4c4f0
--- /dev/nu
43 matches
Mail list logo
