Messages in this thread | | | Subject | Re: Dumpable tasks and ownership of /proc/*/fd | From | (Eric W. Biederman) | Date | Mon, 10 Apr 2006 01:42:03 -0600 |
| |
Petr Baudis <pasky@ucw.cz> writes:
> Dear diary, on Mon, Apr 10, 2006 at 07:43:03AM CEST, I got a letter > where "Eric W. Biederman" <ebiederm@xmission.com> said that... >> Speaking of things why does the *at() emulation need to touch >> /proc/self/fd/*? I may be completely dense but if the practical >> justification for allowing access to /proc/self/fd/ is that we >> already have access then we shouldn't need /proc/self/fd. >> >> I suspect this a matter of convenience where you are prepending >> /proc/self/fd/xxx/ to the path before you open it instead of calling >> fchdir openat() and the doing fchdir back. Have I properly guessed >> how the *at() emulation works? > > Ok, now I'm not completely following you. Only i386 and x86_64 appears > to provide the openat() syscall (only in new kernels, furthermore) and > glibc otherwise emulates openat(n, "relpath") with > open("/proc/self/fd/<n>/relpath"). I don't know of any other way how to > emulate it.
I can think of a couple of ways, but thanks for confirming I properly guessed how the openat emulation was working.
The first point to note is that fixing proc and exporting syscalls to new architectures is going to take about equally long with a chance that fixing proc will take longer because that needs to be understood.
With that said I can think of a couple of different ways to implement openat that won't have proc permission problems.
The most straight forward is: int openat(int dirfd, const char *path, int flags, int mode) { int orig_dir_fd; int result; lock() orig_dir_fd = open("."); fchdir(dirfd); result = open(relpath); fchdir(orig_dir_fd); close(orig_dir_fd); unlock(); return result; }
I suspect something like the above needs to be considered if you want the emulation to work on old kernels, in the presence of suid applications.
I will look at fixing proc but I none of my work on /proc is going to get merged until 2.6.18 at this point.
I doubt a proc permission change could count as a simply a bug fix, and even then it doesn't matter because it won't be available for your emulation.
Although I guess you could attempt to use /proc/self/fd/<n> and if that gets a permission problem try a slower but more reliable path in the emulation.
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |