Re: kern/51595: inconsistent behaviour in statvfs

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/51595; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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
  >  GETCWD_CHECK_ACCESS.
 
 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
 namespace.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost