[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51595: inconsistent behaviour in statvfs
The following reply was made to PR kern/51595; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: kern/51595: inconsistent behaviour in statvfs
Date: Mon, 21 Nov 2016 15:36:50 +0000
On Mon, Nov 21, 2016 at 10:15:01AM +0000, J. Hannken-Illjes wrote:
> > getcwd *should* fail if inside a directory where read (or search)
> > permission is missing.
> This is the current behaviour. It calls getcwd_common() with flag
The original patch in the PR bluntly changes the getcwd internals to
use NOCRED. Are we sure that the GETCWD_CHECK_ACCESS call is
equivalent to (or greater than) the calls that would circumvent?
(yes, I missed the existence of that call last night)
It seems then like the problem is that the logic to force getcwd to
succeed regardless of permissions is missing some stuff and we need
a flag for it in lookup (no! no! gah) and/or readdir.
> > Don't patch it to ignore the credentials; make it check in both
> > cases. Having it succeed some of the time is a bug. (Technically a
> > security bug, but not one anyone is likely to care that much about...)
> > The use of getcwd in statvfs is going to have to take account of this
> > better, but probably a good starting point is to just give EACCES. And
> > yeah, that means things like "df ." will fail with EACCES, which is
> > why it's only a starting point...
> To make it clear: statvfs uses getcwd_common() to lookup the path
> leading to a chroot so it can strip this path from the mount path
> seen from inside the chroot. This lookup should always succeed or
> the path leading to the chroot should be saved on chroot setup.
You can't save the path because it can change. (In theory one could
instrument rename to update the saved path or something, but in
practice this is not very feasible.)
You can't use NOCRED because nfs will blow up; for that matter,
because of rootsquash you can't even necessarily force the lookup to
succeed on nfs.
One could hack nfs to try harder if passed the force flag that doesn't
currently exist. That would probably cover most of the interesting
caes (e.g. have it try the current user first, then try with
manufactured creds using the owner of the directory, then as uid 0)
but will be quite a pain. And it still won't work all the time.
I guess the best solution in the short term is to save the path and
assume that a sysadmin who moves active chroots around deserves the
(relatively minor) consequences. Then try sometime in the future to
figure out a better way to manage the high-level properties of the fs
David A. Holland
Main Index |
Thread Index |