On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote: > Rich Felker <dalias@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
