* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Eric W. Biederman @ 2015-01-09 22:13 UTC (permalink / raw)
To: Rich Felker
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150109212852.GU4574-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
Rich Felker <dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org> writes:
> On Fri, Jan 09, 2015 at 09:09:41PM +0000, 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 around until _exit or exec. In the case where the interpreter
> opens it more than once, you get a failure, but as far as I know
> existing interpreters don't do this, and it's arguably bad design. In
> any case it's a caught error.
And it doesn't work without introducing security vulnerabilities into
the kernel, because it breaks close-on-exec semantics.
All you have to do is pick a file descriptor, good canidates are 0 and
255 and make it a convention that that file descriptor is used for
fexecve. At least when you want to support scripts. Otherwise you can
set close-on-exec.
That results in no accumulation of file descriptors because everyone
always uses the same file descriptor.
Regardless you don't have a patch and you aren't proposing code and the
code isn't actually broken so please go away.
Eric
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-09 22:17 UTC (permalink / raw)
To: Al Viro
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109215042.GM22149@ZenIV.linux.org.uk>
On Fri, Jan 09, 2015 at 09:50:42PM +0000, 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; the magic symlink just
> > sticks around until _exit or exec. In the case where the interpreter
> > opens it more than once, you get a failure, but as far as I know
> > existing interpreters don't do this, and it's arguably bad design. In
> > any case it's a caught error.
>
> You know what's cleaner than that? git revert 27d6ec7ad
> It has just been merged; until 3.19 it's fair game for removal.
>
> And yes, I should've NAKed the damn thing loud and clear, rather than
> asking questions back then, getting no answers and letting it slip.
> Mea culpa.
>
> 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 there
> to cope with the actual intended uses.
Reverting does not fix the problem. There is no way to make fexecve
work for scripts without kernel support, and the needed kernel support
without fexecve would be even nastier, since handling of /proc/self/fd
magic-symlinks would need to be special-cased. The added fexecveat
syscall supports fully /proc-less operation for non-scripts.
Rich
^ permalink raw reply
* Re: [PATCH v4 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
From: Greg KH @ 2015-01-09 22:25 UTC (permalink / raw)
To: Chunyan Zhang
Cc: mark.rutland-5wv7dgnIgG8, arnd-r2nGTMty4D4,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io,
broonie-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, jslaby-AlSwsSmVLrQ,
jason-NLaQJdtUoK4Be96aLqz0jA, heiko-4mtYJXux2i+zQB+pC5nmwQ,
florian.vaussard-p8DiymsW2f8, andrew-g2DYL2Zd6BY,
rrichter-YGCgFSpz5w/QT0dZR+AlfA, hytszk-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
orsonzhai-Re5JQEeQqe8AvxtiuMwx3w, geng.ren-lxIno14LUO0EEoCn2XhGlw,
zhizhou.zhang-lxIno14LUO0EEoCn2XhGlw,
lanqing.liu-lxIno14LUO0EEoCn2XhGlw,
zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w,
wei.qiao-lxIno14LUO0EEoCn2XhGlw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sprdlinux-uGLqWuYN4qMgsBAKwltoeQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, arm-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1417692860-18841-6-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On Thu, Dec 04, 2014 at 07:34:20PM +0800, Chunyan Zhang wrote:
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -247,4 +247,7 @@
> /* MESON */
> #define PORT_MESON 109
>
> +/* SPRD SERIAL */
> +#define PORT_SPRD 110
Please use a tab here, like all other entries have.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-09 22:33 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109221728.GW4574@brightrain.aerifal.cx>
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 there
> > to cope with the actual intended uses.
>
> Reverting does not fix the problem. There is no way to make fexecve
> work for scripts without kernel support, and the needed kernel support
> without fexecve would be even nastier, since handling of /proc/self/fd
> magic-symlinks would need to be special-cased. The added fexecveat
> syscall supports fully /proc-less operation for non-scripts.
Oh, yes it does. It's not *our* problem if it's out of tree and not
a part of ABI. That way if you need it, *you* get to come up with clean
implementation. If it's in-tree you get leverage to push ugly kludges
further in. And frankly, I don't trust you to abstain from using that
leverage in rather nasty ways.
Out of curiosity, how would you expect that "open only once" to work?
All reliable variants I see are beyond sick...
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-09 22:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <87lhlbvbzs.fsf@x220.int.ebiederm.org>
On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote:
> Rich Felker <dalias@aerifal.cx> writes:
>
> > On Fri, Jan 09, 2015 at 09:09:41PM +0000, 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 around until _exit or exec. In the case where the interpreter
> > opens it more than once, you get a failure, but as far as I know
> > existing interpreters don't do this, and it's arguably bad design. In
> > any case it's a caught error.
>
> And it doesn't work without introducing security vulnerabilities into
> the kernel, because it breaks close-on-exec semantics.
I'm curious what those security vulnerabilities would be. The standard
issue with close-on-exec failure (e.g. races) is the leaking of
arbitrary file descriptors (typically, ones opened by other threads or
other unrelated portions of the program) to resources the new process
should not have. "Leaking" of an inode-reference-only (no permissions)
O_PATH fd or pseudo-fd to the script that's to be run does not seem
like a vulnerability to me, and it would only be "leaked" if the
interpreter does something unexpected.
> All you have to do is pick a file descriptor, good canidates are 0 and
> 255 and make it a convention that that file descriptor is used for
> fexecve. At least when you want to support scripts. Otherwise you can
> set close-on-exec.
0 is obviously not a candidate; it's stdin. 255 is also not a
candidate though. Consider for example something like irssi's /upgrade
that's going to have the child inheriting an arbitrary set of file
descriptors that need to keep their original numbers, possibly
including 255. Imposing a script in between should not cause arbitrary
file descriptors to be lost.
> That results in no accumulation of file descriptors because everyone
> always uses the same file descriptor.
>
> Regardless you don't have a patch and you aren't proposing code and the
> code isn't actually broken so please go away.
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 hostility is
really not necessary.
Rich
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-09 22:42 UTC (permalink / raw)
To: Al Viro
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109223300.GO22149@ZenIV.linux.org.uk>
On Fri, Jan 09, 2015 at 10:33:00PM +0000, 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
> > > we not only need procfs mounted, we need a yet-to-be-added kludge in there
> > > to cope with the actual intended uses.
> >
> > Reverting does not fix the problem. There is no way to make fexecve
> > work for scripts without kernel support, and the needed kernel support
> > without fexecve would be even nastier, since handling of /proc/self/fd
> > magic-symlinks would need to be special-cased. The added fexecveat
> > syscall supports fully /proc-less operation for non-scripts.
>
> Oh, yes it does. It's not *our* problem if it's out of tree and not
> a part of ABI. That way if you need it, *you* get to come up with clean
> implementation. If it's in-tree you get leverage to push ugly kludges
> further in. And frankly, I don't trust you to abstain from using that
> leverage in rather nasty ways.
>
> Out of curiosity, how would you expect that "open only once" to work?
> All reliable variants I see are beyond sick...
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 passed could then simply be /dev/fd/%d or
/proc/self/fd/%d, and although this is presently dependent on /proc
being mounted, virtual /dev/fd/* could someday be something completely
independent of procfs. The kernel keeps all the freedom to choose how
to pass the name to the interpreter. I'm not proposing any kernel
API/ABI lock-in and I'm with you in opposing such lock-in.
Rich
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-09 22:57 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150109224252.GY4574-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
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 passed could then simply be /dev/fd/%d or
> /proc/self/fd/%d, and although this is presently dependent on /proc
> being mounted, virtual /dev/fd/* could someday be something completely
> independent of procfs. The kernel keeps all the freedom to choose how
> to pass the name to the interpreter. I'm not proposing any kernel
> API/ABI lock-in and I'm with you in opposing such lock-in.
Huh? open() on procfs symlinks does *NOT* work the way - the symlink is
traversed and after that point there is no information whatsoever how we
got to that vfsmount/dentry pair. I can imagine several kludges that would
work, but they are unspeakably ugly, and do_last() is already far too
convoluted as it is.
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-09 23:12 UTC (permalink / raw)
To: Al Viro
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109225743.GP22149@ZenIV.linux.org.uk>
On Fri, Jan 09, 2015 at 10:57:43PM +0000, 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 causes the kernel to close it whenever it's
> > opened. The pathname passed could then simply be /dev/fd/%d or
> > /proc/self/fd/%d, and although this is presently dependent on /proc
> > being mounted, virtual /dev/fd/* could someday be something completely
> > independent of procfs. The kernel keeps all the freedom to choose how
> > to pass the name to the interpreter. I'm not proposing any kernel
> > API/ABI lock-in and I'm with you in opposing such lock-in.
>
> Huh? open() on procfs symlinks does *NOT* work the way - the symlink is
> traversed and after that point there is no information whatsoever how we
> got to that vfsmount/dentry pair. I can imagine several kludges that would
> work, but they are unspeakably ugly, and do_last() is already far too
> convoluted as it is.
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 action, which is already special for magic
symlinks, can't check a flag on the magic symlink and possibly close
the corresponding file descriptor as part of its action.
In any case, whether/how fexecve works with interpreters is something
the kernel can change without breaking userspace expectations. My goal
is to avoid creating any new API/ABI requirement here.
Rich
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Andy Lutomirski @ 2015-01-09 23:24 UTC (permalink / raw)
To: Rich Felker
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Eric W. Biederman, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109231248.GZ4574@brightrain.aerifal.cx>
On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, Jan 09, 2015 at 10:57:43PM +0000, 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 causes the kernel to close it whenever it's
>> > opened. The pathname passed could then simply be /dev/fd/%d or
>> > /proc/self/fd/%d, and although this is presently dependent on /proc
>> > being mounted, virtual /dev/fd/* could someday be something completely
>> > independent of procfs. The kernel keeps all the freedom to choose how
>> > to pass the name to the interpreter. I'm not proposing any kernel
>> > API/ABI lock-in and I'm with you in opposing such lock-in.
>>
>> Huh? open() on procfs symlinks does *NOT* work the way - the symlink is
>> traversed and after that point there is no information whatsoever how we
>> got to that vfsmount/dentry pair. I can imagine several kludges that would
>> work, but they are unspeakably ugly, and do_last() is already far too
>> convoluted as it is.
>
> 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 action, which is already special for magic
> symlinks, can't check a flag on the magic symlink and possibly close
> the corresponding file descriptor as part of its action.
>
> In any case, whether/how fexecve works with interpreters is something
> the kernel can change without breaking userspace expectations. My goal
> is to avoid creating any new API/ABI requirement here.
>
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 new interface that says "when I'm a script
interpreter, I expect an auxv entry AT_SCRIPT_FD with an open fd with
CLOEXEC set". Then we can directly exec scripts by fd, even with
O_CLOEXEC set, without any races.
--Andy
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-09 23:36 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150109231248.GZ4574@brightrain.aerifal.cx>
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 action, which is already special for magic
> symlinks, can't check a flag on the magic symlink and possibly close
> the corresponding file descriptor as part of its action.
_What_ action? ->follow_link()? As in "the same thing that e.g.
stat(2) would trigger"?
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-09 23:37 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Eric W. Biederman, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <CALCETrUpr5kqNm5M5z=RxM9T7DOQB3-Le2gxGM=D7+cpWVRQaQ@mail.gmail.com>
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Fri, Jan 09, 2015 at 10:57:43PM +0000, 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 causes the kernel to close it whenever it's
> >> > opened. The pathname passed could then simply be /dev/fd/%d or
> >> > /proc/self/fd/%d, and although this is presently dependent on /proc
> >> > being mounted, virtual /dev/fd/* could someday be something completely
> >> > independent of procfs. The kernel keeps all the freedom to choose how
> >> > to pass the name to the interpreter. I'm not proposing any kernel
> >> > API/ABI lock-in and I'm with you in opposing such lock-in.
> >>
> >> Huh? open() on procfs symlinks does *NOT* work the way - the symlink is
> >> traversed and after that point there is no information whatsoever how we
> >> got to that vfsmount/dentry pair. I can imagine several kludges that would
> >> work, but they are unspeakably ugly, and do_last() is already far too
> >> convoluted as it is.
> >
> > 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 action, which is already special for magic
> > symlinks, can't check a flag on the magic symlink and possibly close
> > the corresponding file descriptor as part of its action.
> >
> > In any case, whether/how fexecve works with interpreters is something
> > the kernel can change without breaking userspace expectations. My goal
> > is to avoid creating any new API/ABI requirement here.
>
> 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 new interface that says "when I'm a script
> interpreter, I expect an auxv entry AT_SCRIPT_FD with an open fd with
> CLOEXEC set". Then we can directly exec scripts by fd, even with
> O_CLOEXEC set, without any races.
This is also acceptable, but I don't think you'd really need a special
header flag. Just pass it, and also pass /dev/fd/%d or
/proc/self/fd/%d in argv[]. If the interpreter supports it, everything
works fine. If not, it still works as long as /proc is mounted, but
with a partial fd leak. (Note: the leak is not so bad since the
interpreter would inherit a close-on-exec fd and thus would not leak
it further.)
Aside from setting up the new auxv entry, the main trick the kernel
would have to do is bypassing FD_CLOEXEC at exec time while keeping
the FD_CLOEXEC flag present on the fd after exec.
Rich
^ permalink raw reply
* Re: [v8 2/5] ext4: adds project ID support
From: Dave Chinner @ 2015-01-09 23:46 UTC (permalink / raw)
To: Jan Kara
Cc: Andreas Dilger, Li Xi, Linux Filesystem Development List,
ext4 development, linux-api-u79uwXL29TY76Z2rM5mHXA,
Theodore Ts'o, Al Viro, Christoph Hellwig, Dmitry Monakhov
In-Reply-To: <20150109094758.GA2576-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
On Fri, Jan 09, 2015 at 10:47:58AM +0100, Jan Kara wrote:
> On Thu 08-01-15 15:20:21, Andreas Dilger wrote:
> > On Jan 8, 2015, at 1:26 AM, Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org> wrote:
> > > On Tue 09-12-14 13:22:25, Li Xi wrote:
> > >> This patch adds a new internal field of ext4 inode to save project
> > >> identifier. Also a new flag EXT4_INODE_PROJINHERIT is added for
> > >> inheriting project ID from parent directory.
> > > I have noticed one thing you apparently changed in v7 of the patch set.
> > > See below.
> > >
> > >> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > >> index 29c43e7..8bd1da9 100644
> > >> --- a/fs/ext4/ext4.h
> > >> +++ b/fs/ext4/ext4.h
> > >> @@ -377,16 +377,18 @@ struct flex_groups {
> > >> #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */
> > >> #define EXT4_EOFBLOCKS_FL 0x00400000 /* Blocks allocated beyond EOF */
> > >> #define EXT4_INLINE_DATA_FL 0x10000000 /* Inode has inline data. */
> > >> +#define EXT4_PROJINHERIT_FL FS_PROJINHERIT_FL /* Create with parents projid */
> > > How did FS_PROJINHERIT_FL get here? There used to be 0x20000000 in older
> > > version of the patch set which is correct - this definition is defining
> > > ext4 on-disk format. As such it is an ext4 specific flag and should be
> > > definined to a fixed constant independed of any other filesystem. It seems
> > > you are somewhat mixing what is an on-disk format flag value and what is a
> > > flag value passed from userspace. These two may be different things and
> > > you need to convert between the values when getting / setting flags...
> >
> > Currently the EXT4_*_FL and FS_*_FL values are all identical, and there
> > is no reason to change that before it is actually needed. Since the
> > FS_PROJINHERIT_FL is used via chattr/lsattr from userspace, this value
> > must also be kept the same in the future to avoid API breakage, so there
> > is no reason to worry about incompatibilities.
> Agreed. I was somewhat worried about having on-disk flag defined through
> the external non-ext4 define but you are right that neither can really
> change once we ship a kernel with it.
>
> > See also the [v8 5/5] patch, which is changing the EXT4_*_FL values to
> > use FS_*_FL constants, where applicable, so that it is more clear that
> > these values need to be the same.
> OK, I've missed that. So if things will be consistent again, I'm fine
> with the change.
Except that I NACK'd that change (i.e patch 4/5) because it's out of
scope of a "support project quota" patchset. not to mention that it
is broken because it exhausts the flags space with ext4 specific
flags and prevents future expansion of the ioctl structure.
Any extension to the ioctl needs to be done in a spearate patch set,
with separate justification. This patch set should only implement
the very minimum needed to use the project quota ioctl flags....
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-10 0:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Rich Felker, David Drysdale, Michael Kerrisk (man-pages),
Eric W. Biederman, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <CALCETrUpr5kqNm5M5z=RxM9T7DOQB3-Le2gxGM=D7+cpWVRQaQ@mail.gmail.com>
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 new interface that says "when I'm a script
> interpreter, I expect an auxv entry AT_SCRIPT_FD with an open fd with
> CLOEXEC set". Then we can directly exec scripts by fd, even with
> O_CLOEXEC set, without any races.
Amazing. Let me see if I got it straight - you want a magical Linux-only
flag to mark the binaries that might be used as interpreters. _Plus_ the
Linux-only logics in their source to go with that. With corresponding kludges
to parsing the command line (you know, like #!/usr/bin/make -f as the first
line in a script - somehow it should recognize the deep magic of the oh
so fucking superior interface and suppress the normal behaviour). Maintained
by hell knows whom. Onna stick. Inna bun. CMOT Dibbler would be proud...
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Eric W. Biederman @ 2015-01-10 1:17 UTC (permalink / raw)
To: Rich Felker
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150109223843.GX4574-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
Rich Felker <dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org> 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 hostility is
> really not necessary.
Conforming to what?
The open group fexecve says nothing about requiring a file descriptor
passed to fexecve to have O_CLOEXEC.
Further looking at open group specification of exec it seems to indicate
the preferred way to handle this is for the kernel to return O_NOEXEC
and then libc gets to figure out how to run the shell script. Is that
the kind of ``conforming'' implementation you are looking for?
Eric
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-10 1:33 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Al Viro, David Drysdale, Michael Kerrisk (man-pages),
Andy Lutomirski, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87mw5rtowa.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> Rich Felker <dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org> 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 hostility is
> > really not necessary.
>
> Conforming to what?
>
> The open group fexecve says nothing about requiring a file descriptor
> passed to fexecve to have O_CLOEXEC.
It doesn't require it but it allows it, and in multithreaded programs
that might run child processes (or library code that might be used in
such situations), O_CLOEXEC is mandatory everywhere to avoid fd leaks.
> Further looking at open group specification of exec it seems to indicate
> the preferred way to handle this is for the kernel to return O_NOEXEC
> and then libc gets to figure out how to run the shell script. Is that
> the kind of ``conforming'' implementation you are looking for?
This is a complex issue, and does not apply to native #! support
(which is a supported executable format and thus not ENOEXEC) but
rather standard POSIX shell scripts (which don't have a #! line at
all). In this case the behavior of fexecve is perhaps under-specified.
However, in cases where execve would succeed (without causing
ENOEXEC), I think it's at least undesirable, if not non-conforming,
for fexecve to fail.
Should we request clarification from the Austin Group?
Rich
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-10 3:03 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150109233644.GR22149-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Fri, Jan 09, 2015 at 11:36:44PM +0000, 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 are bound to the inode of the open file. I
> > don't see why this action, which is already special for magic
> > symlinks, can't check a flag on the magic symlink and possibly close
> > the corresponding file descriptor as part of its action.
>
> _What_ action? ->follow_link()? As in "the same thing that e.g.
> stat(2) would trigger"?
To elaborate a bit: the fundamental method for symlink traversal is
->follow_link(). It gets dentry of the object itself + opaque context.
Usually it just obtains some string (== symlink contents) and calls
nd_set_link(context, string). In that case the string will be interpreted
by its callers in usual way. Another possibility is to call
nd_jump_link(context, location), which will reset the current position
(directory in which the symlink has been found and relative to which it
would be interpreted) to given location in tree. It might actually do
both - then the string will be interpreted relative to the new location.
Once the pathname resolution is done with the string stored by nd_set_link(),
it calls another method - ->put_link(). That one releases the object
that contains this string; it gets an opaque pointer returned by
->follow_link(). Returning ERR_PTR(-Esomething) indicates an error, so does
nd_set_link(context, ERR_PTR(-Esomething)).
readlink(2) is using a different method (->readlink()) and any object whose
->follow_link() only uses nd_set_link() can use generic_readlink as its
->readlink instance - that will call ->follow_link(), copy the string
stored by nd_set_link() to userland buffer and use ->put_link() to release
whatever needs to be released. Most of the symlinks are doing just that.
procfs "magical" symlinks have ->follow_link() that uses nd_jump_link();
they obviously can't use generic_readlink() (there is no string left
by ->follow_link() for caller to traverse), so they have non-standard
->readlink() instances - ones that use d_path() to generate a plausible
pathname of the would-be destination of their ->follow_link(). Or something
like pipe:[696969], etc.
Note, however, that ->readlink() is used only by readlink(2) syscall; as far
as pathname resolution is concerned it is completely irrelevant. What matters
is ->follow_link().
Now, the callers do not know (and do not care) what a particular symlink _is_.
A symlink is just a dentry with inode that has non-NULL ->follow_link()
method. That's it. Moreover, _any_ pathname resolution is using the
same method for symlink traversal, be it open(2), stat(2), whatever. If
a symlink is to be traversed, that's it - the only choice VFS has is whether
to traverse it at all or not (think of stat(2) vs lstat(2) difference, or
O_NOFOLLOW, etc.)
_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/<n>?
And doing that _during_ the traversal would really suck - stray ls -lR /proc
could race with that open() done by script interpreter.
It might be possible to work around that, but trying that rapidly gets into
very ugly territory, *especially* since the handling of the final component
of open(2) (fs/namei.c:do_last()) is already far too convoluted.
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-10 3:41 UTC (permalink / raw)
To: Al Viro
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150110030300.GU22149@ZenIV.linux.org.uk>
On Sat, Jan 10, 2015 at 03:03:00AM +0000, Al Viro wrote:
> On Fri, Jan 09, 2015 at 11:36:44PM +0000, 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 are bound to the inode of the open file. I
> > > don't see why this action, which is already special for magic
> > > symlinks, can't check a flag on the magic symlink and possibly close
> > > the corresponding file descriptor as part of its action.
> >
> > _What_ action? ->follow_link()? As in "the same thing that e.g.
> > stat(2) would trigger"?
>
> To elaborate a bit: the fundamental method for symlink traversal is
> ->follow_link(). It gets dentry of the object itself + opaque context.
> Usually it just obtains some string (== symlink contents) and calls
> nd_set_link(context, string). In that case the string will be interpreted
> by its callers in usual way. Another possibility is to call
> nd_jump_link(context, location), which will reset the current position
> (directory in which the symlink has been found and relative to which it
> would be interpreted) to given location in tree. It might actually do
> both - then the string will be interpreted relative to the new location.
> Once the pathname resolution is done with the string stored by nd_set_link(),
> it calls another method - ->put_link(). That one releases the object
> that contains this string; it gets an opaque pointer returned by
> ->follow_link(). Returning ERR_PTR(-Esomething) indicates an error, so does
> nd_set_link(context, ERR_PTR(-Esomething)).
>
> readlink(2) is using a different method (->readlink()) and any object whose
> ->follow_link() only uses nd_set_link() can use generic_readlink as its
> ->readlink instance - that will call ->follow_link(), copy the string
> stored by nd_set_link() to userland buffer and use ->put_link() to release
> whatever needs to be released. Most of the symlinks are doing just that.
>
> procfs "magical" symlinks have ->follow_link() that uses nd_jump_link();
> they obviously can't use generic_readlink() (there is no string left
> by ->follow_link() for caller to traverse), so they have non-standard
> ->readlink() instances - ones that use d_path() to generate a plausible
> pathname of the would-be destination of their ->follow_link(). Or something
> like pipe:[696969], etc.
>
> Note, however, that ->readlink() is used only by readlink(2) syscall; as far
> as pathname resolution is concerned it is completely irrelevant. What matters
> is ->follow_link().
>
> Now, the callers do not know (and do not care) what a particular symlink _is_.
> A symlink is just a dentry with inode that has non-NULL ->follow_link()
> method. That's it. Moreover, _any_ pathname resolution is using the
> same method for symlink traversal, be it open(2), stat(2), whatever. If
> a symlink is to be traversed, that's it - the only choice VFS has is whether
> to traverse it at all or not (think of stat(2) vs lstat(2) difference, or
> O_NOFOLLOW, etc.)
>
> _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/<n>?
Thanks for clarifying how this all works in the kernel. It makes it
easier to understand what the costs (especially complexity costs) of
different implementation options might be for the kernel.
> And doing that _during_ the traversal would really suck - stray ls -lR /proc
> could race with that open() done by script interpreter.
IMO this one issue is easily solvable by limiting the special action
to calls by the owning pid.
Rich
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Al Viro @ 2015-01-10 4:14 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150110034144.GC4574@brightrain.aerifal.cx>
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/<n>?
>
> Thanks for clarifying how this all works in the kernel. It makes it
> easier to understand what the costs (especially complexity costs) of
> different implementation options might be for the kernel.
>
> > And doing that _during_ the traversal would really suck - stray ls -lR /proc
> > could race with that open() done by script interpreter.
>
> IMO this one issue is easily solvable by limiting the special action
> to calls by the owning pid.
Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
etc.) before bothering with open(2), you'll get screwed. Moreover, if it
does so only in case when you have something specific in environment,
you'll have the devil of the time trying to figure out how to reproduce
such a bug report...
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Rich Felker @ 2015-01-10 5:57 UTC (permalink / raw)
To: Al Viro
Cc: David Drysdale, Michael Kerrisk (man-pages), Eric W. Biederman,
Andy Lutomirski, Meredydd Luff, linux-kernel@vger.kernel.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux
In-Reply-To: <20150110041457.GV22149@ZenIV.linux.org.uk>
On Sat, Jan 10, 2015 at 04:14:57AM +0000, 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 or that of any normal /proc/self/fd/<n>?
> >
> > Thanks for clarifying how this all works in the kernel. It makes it
> > easier to understand what the costs (especially complexity costs) of
> > different implementation options might be for the kernel.
> >
> > > And doing that _during_ the traversal would really suck - stray ls -lR /proc
> > > could race with that open() done by script interpreter.
> >
> > IMO this one issue is easily solvable by limiting the special action
> > to calls by the owning pid.
>
> 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/getxattr/access/whatever followed by open is always a TOCTOU
race. The correct sequence of actions is always open followed by
fstat/fgetxattr/...
> Moreover, if it
> does so only in case when you have something specific in environment,
> you'll have the devil of the time trying to figure out how to reproduce
> such a bug report...
Yes, this is a more serious concern. For example, if a shell processes
$HISTFILE or something before opening the script. I'm starting to
prefer the idea of just refusing to honor the close-on-exec flag for
the fd passed to fexecve but preserving it, and letting the
interpreter close the file itself if it wants to. This could be done
with or without the new auxv entry stuff.
Rich
^ permalink raw reply
* Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
From: Darren Hart @ 2015-01-10 6:57 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: Brian Norris, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
linux-api-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
libsmbios-devel-XtjxT7Vmt5ZskZv2Y/7f+AC/G2K4zDHf,
Srinivas_G_Gowda-8PEkshWhKlo, Michael_E_Brown-8PEkshWhKlo,
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
A.Sloman-dxBOTFGcEFw2EctHIo1CcQ
In-Reply-To: <1636595.UbTko9mUNA@xps13>
On Wed, Dec 31, 2014 at 12:20:59PM +0100, Gabriele Mazzotta wrote:
> On Tuesday 30 December 2014 21:31:49 Brian Norris wrote:
> > Hi,
> >
> > On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote:
> > > Add the documentation for the new sysfs interface of dell-laptop
> > > that allows to configure the keyboard illumination on Dell systems.
> > >
> > > Signed-off-by: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > .../ABI/testing/sysfs-platform-dell-laptop | 60 ++++++++++++++++++++++
> > > 1 file changed, 60 insertions(+)
> > > create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > new file mode 100644
> > > index 0000000..7969443
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > @@ -0,0 +1,60 @@
> > > +What: /sys/class/leds/dell::kbd_backlight/als_setting
> > > +Date: December 2014
> > > +KernelVersion: 3.19
> > > +Contact: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> > > + Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > +Description:
> > > + This file allows to control the automatic keyboard
> > > + illumination mode on some systems that have an ambient
> > > + light sensor. Write 1 to this file to enable the auto
> > > + mode, 0 to disable it.
> > [...]
> >
> > This entry appears wrong, or at least incomplete. My system boots with a
> > default value of 18, and the 'set' implementation accepts any value from
> > 0 to 255.
> >
> > According to the comments in dell-laptop.c, the value actually means
> > something different than on/off:
> >
> > cbArg3, byte0 Desired setting of ALS value that turns the light on or off.
> >
> > Admittedly, I'm not clear on what the intended interface is, as I've
> > never had the ALS / keyboard backlight controls all working properly on
> > my laptop in the first place, but I thought this would be the right
> > place to ask about getting the documentation and driver in sync.
>
> Hi,
>
> You are perfectly right, the documentation is wrong and I'm sorry for
> that. als_setting should allow you to define when the keyboard
> backlight has to be turned on or off depending on the value reported
> by the ambient light sensor.
>
> Please note that not everything that is in libsmbios [1] is implemented
> in the kernel driver. Take a look at it, recently there have been few
> changes related to the ALS settings. Probably they are not needed given
> that you are able to set the threshold with the current kernel driver,
> but you might find something interesting.
>
> I'll submit a patch to correct the documentation, thanks for reporting.
Hi Gabriele,
Have I missed a patch from you for this? I'd like to see this corrected in the
3.19 rc cycle.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Michael Kerrisk (man-pages) @ 2015-01-10 7:13 UTC (permalink / raw)
To: Eric W. Biederman, Rich Felker
Cc: mtk.manpages, Al Viro, David Drysdale, Andy Lutomirski,
Meredydd Luff, linux-kernel@vger.kernel.org, Andrew Morton,
David Miller, Thomas Gleixner, Stephen Rothwell, Oleg Nesterov,
Ingo Molnar, H. Peter Anvin, Kees Cook, Arnd Bergmann,
Christoph Hellwig, X86 ML, linux-arch, Linux API, sparclinux
In-Reply-To: <87lhlbvbzs.fsf@x220.int.ebiederm.org>
On 01/09/2015 11:13 PM, Eric W. Biederman wrote:
> Rich Felker <dalias@aerifal.cx> writes:
>
>> On Fri, Jan 09, 2015 at 09:09:41PM +0000, 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 around until _exit or exec. In the case where the interpreter
>> opens it more than once, you get a failure, but as far as I know
>> existing interpreters don't do this, and it's arguably bad design. In
>> any case it's a caught error.
>
> And it doesn't work without introducing security vulnerabilities into
> the kernel, because it breaks close-on-exec semantics.
>
> All you have to do is pick a file descriptor, good canidates are 0 and
> 255 and make it a convention that that file descriptor is used for
> fexecve. At least when you want to support scripts. Otherwise you can
> set close-on-exec.
>
> That results in no accumulation of file descriptors because everyone
> always uses the same file descriptor.
>
> Regardless you don't have a patch and you aren't proposing code and the
> code isn't actually broken so please go away.
Eric,
This style of response isn't helpful. Suggesting that people must have
a patch in hand in order to have a conversation about kernel development
means a lot of clever people are going to be excluded from important
conversations. Those clever people are some user-space developers
who develop the software that the kernel interacts with--you know, the
user-space that is the kernel's raison-d'être.
Rich, as far as I've seen, is one of those clever people--he implemented
and maintains a (pretty much complete?) standard C library, so when he
comes to a conversation like this, I think it's best to start with
the assumption that he's thought long and hard about the problem, and
seemingly hostile responses as you (and Al) make above don't do much
to advance the conversation to a solution.
And there is a problem [*] and nothing I've seen so far in this
conversation seems to provide a solution within the current
kernel implementation (but, maybe I am not clever enough to see it).
==
[*] A summary of the problem for bystanders:
[0.a] Some people want a solution to implementing fexecve()
(http://man7.org/linux/man-pages/man3/fexecve.3.html )
in the absence of /proc (which is currently used for
the implementation). The new execveat() is a stepping
stone to that solution.
[0.b] POSIX permits, but does not require, the FD_CLOEXEC
(close-on-exec) file descriptor flag to be set on the
file descriptor passed to fexecve().
[1] The sequence:
* Open a script file, to get a descriptor, 'fd'
* Set the close-on-exec flag on 'fd'
* execveat(fd, NULL, argv, envp, AT_EMPTY_PATH)
fails in the execveat() because by the time the script
interpreter has been loaded, 'fd' has been closed because
of the close-on-exec flag.
[2] Omitting the use of close-on-exec on the FD given to
fexecve()/execveat() means that the execed script
receives a superfluous file descriptor that refers to the
script file. The script cannot determine that there is such
an FD or which FD it is without some some messy special-case
hacking to inspect its environment (and that hacking must be
based on /proc, AFAICT!)
[3] Scripts won't do the check in [2], with the result that
that there'll be descriptor leaks in some cases where
fexecve()/execveat() is used repeatedly.
[4] (As Rich points out in a reply to the parent message, the
solution suggested above of using a fixed file descriptor
for fexecve() does not solve the problem either.)
For an example of the leak, consider the following simple program
and script. The program is just a simple command-line interface to
exercise execveat():
=====
/* t_execveat.c
*/
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#define __NR_execveat 322 /* x86-64 */
static int execveat(int dirfd, const char *pathname, char *const argv[],
char *const envp[], int flags)
{
return syscall(__NR_execveat, dirfd, pathname, argv, envp, flags);
}
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
} while (0)
extern char **environ;
int
main(int argc, char *argv[])
{
int flags, dirfd;
char *path;
flags = 0;
if (argc < 4) {
fprintf(stderr, "%s dirfd-path path argv0 [argvN...]\n", argv[0]);
fprintf(stderr, "\tSpecify 'dirfd' as '-' to get AT_FDCWD\n");
fprintf(stderr, "\tSpecify 'path' as an empty string to get "
"AT_EMPTY_PATH\n");
exit(EXIT_FAILURE);
}
if (argv[1][0] == '-')
dirfd = AT_FDCWD;
else {
dirfd = open(argv[1], O_RDONLY);
if (dirfd == -1)
errExit("open");
}
path = argv[2];
if (strlen(path) == 0)
flags = AT_EMPTY_PATH;
execveat(dirfd, path, &argv[3], environ, flags);
errExit("execveat");
exit(EXIT_SUCCESS);
}
=====
And then a simple script (necho.sh) that recursively invokes itself using
the above program demonstrates the problem.
=====
#!/bin/sh
echo
echo '$0 =' $0
ls -l /proc/$$/fd
./t_execveat ./necho.sh "" arg1 # $arg
=====
When we run this script, we see:
=====
# chmod +x necho.sh
# ./t_execveat ./necho.sh "" arg1
$0 = /dev/fd/3
total 0
lrwx------. 1 root root 64 Jan 10 07:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jan 10 07:59 1 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 199 -> /home/mtk/necho.sh
lrwx------. 1 root root 64 Jan 10 07:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 3 -> /home/mtk/necho.sh
$0 = /dev/fd/4
total 0
lrwx------. 1 root root 64 Jan 10 07:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jan 10 07:59 1 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 199 -> /home/mtk/necho.sh
lrwx------. 1 root root 64 Jan 10 07:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 3 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 4 -> /home/mtk/necho.sh
$0 = /dev/fd/5
total 0
lrwx------. 1 root root 64 Jan 10 07:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jan 10 07:59 1 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 199 -> /home/mtk/necho.sh
lrwx------. 1 root root 64 Jan 10 07:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 3 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 4 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 5 -> /home/mtk/necho.sh
$0 = /dev/fd/6
total 0
lrwx------. 1 root root 64 Jan 10 07:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jan 10 07:59 1 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 199 -> /home/mtk/necho.sh
lrwx------. 1 root root 64 Jan 10 07:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 3 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 4 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 5 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 6 -> /home/mtk/necho.sh
$0 = /dev/fd/7
total 0
lrwx------. 1 root root 64 Jan 10 07:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jan 10 07:59 1 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 199 -> /home/mtk/necho.sh
lrwx------. 1 root root 64 Jan 10 07:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jan 10 07:59 3 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 4 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 5 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 6 -> /home/mtk/necho.sh
lr-x------. 1 root root 64 Jan 10 07:59 7 -> /home/mtk/necho.sh
[and so on until we run out of file descriptors]
=====
(I think the FD 199 in the above output is some bash(1) artifact, unrelated
to the conversation at hand.)
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Michael Kerrisk (man-pages) @ 2015-01-10 7:38 UTC (permalink / raw)
To: Rich Felker
Cc: mtk.manpages, David Drysdale, Eric W. Biederman, Andy Lutomirski,
Alexander Viro, Meredydd Luff, linux-kernel, Andrew Morton,
David Miller, Thomas Gleixner, Stephen Rothwell, Oleg Nesterov,
Ingo Molnar, H. Peter Anvin, Kees Cook, Arnd Bergmann,
Christoph Hellwig, x86, linux-arch, linux-api, sparclinux
In-Reply-To: <20150109161302.GQ4574@brightrain.aerifal.cx>
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 <drysdale@google.com>
>>> ---
>>> man2/execveat.2 | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 153 insertions(+)
>>> create mode 100644 man2/execveat.2
>>
>> David,
>>
>> Thanks for the very nicely prepared man page. I've done
>> a few very light edits, and will release the version below
>> with the next man-pages release.
>>
>> I have one question. In the message accompanying
>> commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 you wrote:
>>
>> The filename fed to the executed program as argv[0] (or the name of the
>> script fed to a script interpreter) will be of the form "/dev/fd/<fd>"
>> (for an empty filename) or "/dev/fd/<fd>/<filename>", effectively
>> reflecting how the executable was found. This does however mean that
>> execution of a script in a /proc-less environment won't work; also, script
>> execution via an O_CLOEXEC file descriptor fails (as the file will not be
>> accessible after exec).
>>
>> How does one produce this situation where the execed program sees
>> argv[0] as a /dev/fd path? (i.e., what would the execveat()
>> call look like?) I tried to produce this scenario, but could not.
>
> I think this is wrong. argv[0] is an arbitrary string provided by the
> caller and would never be derived from the fd passed. 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 long-term intent should be that
> script execution this way should work. IIRC this was discussed earlier
> in the thread.
I agree, that something needs to be said. What I instead did was
added "See BUGS" to the ENOEXEC error, and then this text:
BUGS
The ENOENT error described above means that it is not possible
possible to set the close-on-exec flag on the file descriptor
given to a call of the form:
execveat(fd, "", argv, envp, AT_EMPTY_PATH);
However, the inability to set the close-on-exec flag means that a
file descriptor referring to the script leaks through to the
script itself. As well as wasting a file descriptor, this leak‐
age can lead to file-descriptor exhaustion in scenarios where
scripts recursively employ exceveat() (or a future fexecve(3)
implementation that might be based on execveat()).
Okay?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Michael Kerrisk (man-pages) @ 2015-01-10 7:43 UTC (permalink / raw)
To: David Drysdale, Rich Felker
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Eric W. Biederman,
Andy Lutomirski, Alexander Viro, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Christoph Hellwig, X86 ML, linux-arch, Linux API,
sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAHse=S88Jy5ZKM_VY5onfvxX7dTMngnxuHfuLeSuzvKvQNP19A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/09/2015 06:46 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker <dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org> 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 <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> man2/execveat.2 | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 153 insertions(+)
>>>> create mode 100644 man2/execveat.2
>>>
>>> David,
>>>
>>> Thanks for the very nicely prepared man page. I've done
>>> a few very light edits, and will release the version below
>>> with the next man-pages release.
>>>
>>> I have one question. In the message accompanying
>>> commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 you wrote:
>>>
>>> The filename fed to the executed program as argv[0] (or the name of the
>>> script fed to a script interpreter) will be of the form "/dev/fd/<fd>"
>>> (for an empty filename) or "/dev/fd/<fd>/<filename>", effectively
>>> reflecting how the executable was found. This does however mean that
>>> execution of a script in a /proc-less environment won't work; also, script
>>> execution via an O_CLOEXEC file descriptor fails (as the file will not be
>>> accessible after exec).
>>>
>>> How does one produce this situation where the execed program sees
>>> argv[0] as a /dev/fd path? (i.e., what would the execveat()
>>> call look like?) I tried to produce this scenario, but could not.
>>
>> I think this is wrong. argv[0] is an arbitrary string provided by the
>> caller and would never be derived from the fd passed.
>
> Yeah, I think I just wrote that wrong, it's only relevant for scripts.
> As Rich says, for normal binaries argv[0] is just the argv[0] that
> was passed into the execve[at] call. For a script, the code in
> fs/binfmt_script.c will remove the original argv[0] and put the
> interpreter name and the script filename (e.g. "/bin/sh",
> "/dev/fd/6/script") in as 2 arguments in its place.
Yep, got it now.
> [As an aside, IIRC the filename does get put into the new
> process's memory, up above the environment strings -- but
> that copy isn't visible via argv nor envp.]
>
>> 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 long-term intent should be that
>> script execution this way should work. IIRC this was discussed earlier
>> in the thread.
>
> I may be misremembering, but I thought we hoped to be able to fix
> execveat of a script without /proc in future, but didn't expect to fix
> execveat of a script via an O_CLOEXEC fd (because in the latter
> case the fd gets closed before the script interpreter runs, so even
> if the interpreter (or a special filesystem) does clever things for names
> starting with "/dev/fd/..." the file descriptor is already gone).
See my other replies (and of course, Rich's). It does seem there is
a real problem to be solved here.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)
From: Michael Kerrisk (man-pages) @ 2015-01-10 7:56 UTC (permalink / raw)
To: David Drysdale
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Eric W. Biederman,
Andy Lutomirski, Alexander Viro, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton, David Miller, Thomas Gleixner, Stephen Rothwell,
Oleg Nesterov, Ingo Molnar, H. Peter Anvin, Kees Cook,
Arnd Bergmann, Rich Felker, Christoph Hellwig, X86 ML, linux-arch,
Linux API, sparclinux-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAHse=S9kRj00eRbB+7DQd39Cso1O2LcmZpBVCbuUa9EwRQKv_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/09/2015 07:02 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 3:47 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>>> Signed-off-by: David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> man2/execveat.2 | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 153 insertions(+)
>>> create mode 100644 man2/execveat.2
>>
>> David,
>>
>> Thanks for the very nicely prepared man page. I've done
>> a few very light edits, and will release the version below
>> with the next man-pages release.
>
> Many thanks, one error (of mine) in 2 places pointed out below.
Well, the first error was yours. The second error was mine,
when I replicated your info about AT_SYMLINK_NOFOLLOW
into the ERRORS without verifying it. (Sorry about that!)
Both cases fixed now.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
From: Brian Norris @ 2015-01-10 8:21 UTC (permalink / raw)
To: Darren Hart
Cc: Gabriele Mazzotta, mjg59, linux-api, platform-driver-x86,
Linux Kernel, libsmbios-devel, Srinivas_G_Gowda, Michael_E_Brown,
pali.rohar, Aaron Sloman
In-Reply-To: <20150110065714.GB104814@vmdeb7>
On Fri, Jan 9, 2015 at 10:57 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Wed, Dec 31, 2014 at 12:20:59PM +0100, Gabriele Mazzotta wrote:
>> You are perfectly right, the documentation is wrong and I'm sorry for
>> that. als_setting should allow you to define when the keyboard
>> backlight has to be turned on or off depending on the value reported
>> by the ambient light sensor.
>>
>> Please note that not everything that is in libsmbios [1] is implemented
>> in the kernel driver. Take a look at it, recently there have been few
>> changes related to the ALS settings. Probably they are not needed given
>> that you are able to set the threshold with the current kernel driver,
>> but you might find something interesting.
>>
>> I'll submit a patch to correct the documentation, thanks for reporting.
>
> Have I missed a patch from you for this? I'd like to see this corrected in the
> 3.19 rc cycle.
https://lkml.org/lkml/2015/1/2/63
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox