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 07:26:43 +0000

 On Thu, Nov 03, 2016 at 02:20:01PM +0000, Thomas Klausner wrote:
  > From: Thomas Klausner <wiz%NetBSD.org@localhost>
  > To: gnats-bugs%NetBSD.org@localhost
  > Cc: 
  > Subject: Re: kern/51595: inconsistent behaviour in statvfs
  > Date: Thu, 3 Nov 2016 15:17:26 +0100
  > 
  >  On Thu, Nov 03, 2016 at 02:10:00PM +0000, Christos Zoulas wrote:
  >  >  Please explain what happens. I.e. what it returns in the error case
  >  >  and what it should return.
  >  
  >  IIUC:
  >  
  >  kern/vfs_getcwd.c in getcwd_scandir calls VOP_LOOKUP for ".." to strip
  >  off the chroot path from paths returned to programs inside the chroot.
  >  This fails with EACCES, but should succeed.
  >  
  >  The reason is that in some cases, this is called with the pbulk user
  >  credentials and fails, because pbulk cannot enter /archive/sandboxes;
  >  in some cases it was previously called in another way with root
  >  credentials, and the call originating from the pbulk user uses the
  >  cached entry and everything works fine.
 
 getcwd *should* fail if inside a directory where read (or search)
 permission is missing.
 
 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...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost