Re: 2.6.16-rc5-mm1

[ebiederm@xmission.com (Eric W. Biederman)]

Paul Jackson <pj@sgi.com> writes:

> Eric wrote:
>> The logic is can I access this file in some other way besides through
>> /proc.
>> 
>> When applied to /proc/<pid>/exe
>> When applied to /proc/<pid>/root
>> When applied to /proc/<pid>/cwd
>
> I can't make sense of the above.  Could you elaborate?

Sorry.  What I ment was when applied to the above files the
permission checks are not quite correct because I should check
to see if you share a fs_struct with them, checking for a shared
files_struct for exe,root,cwd is nonsense.

The permission check is not quite in the right place yet
in /proc.

The logical check which I have implemented imperfectly is:
Without going through /proc/fd can I see this file.

Part of the reason this happens now is the old check
unchanged since 2.2 was it only checked to see if the two
processes were in the same chroot.  I made the check test
the actual files that were returned.  Which is much more
correct, and much more likely to prevent information leaks.

> And explain how any of these permission checks fail for
> a root shell?

Because I probably need a check something like
if (capable(CAP_DAC_OVERRIDE))
	return 0;
To allow an appropriately privileged root user to do anything.

The short answer is that I bug fixed the permission checks into working
but that is not sufficient for the permission checks to be correct. :(

These checks were previously done so badly they were mistaken for
generic permission checks that all files in /proc should have.  Which
resulted in tons of useless cruft.

At this point the code is working as designed but it is clearly not
working as it needs to.

I am also beginning to think that readlink and followlink
should have different permissions.  Especially to keep fuser
and his friends happy.

I am glad I found this issue with permissions on /proc/<pid>/fd,
but it is clear there is still more todo.

Ok. Now back to hunting bugs that crash the kernel.


Eric