Re: Dumpable tasks and ownership of /proc/*/fd

[Eric W. Biederman]

Petr Baudis <pasky@xxxxxx> writes:

> Dear diary, on Mon, Apr 10, 2006 at 07:43:03AM CEST, I got a letter
> where "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/