Re: kern/51595: inconsistent behaviour in statvfs

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

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

From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51595: inconsistent behaviour in statvfs
Date: Mon, 21 Nov 2016 11:10:54 +0100

 > On 21 Nov 2016, at 08:30, David Holland <dholland-bugs%netbsd.org@localhost> wrote:
 > 
 > 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.
 
 This is the current behaviour.  It calls getcwd_common() with flag
 GETCWD_CHECK_ACCESS.
 
 > 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.
 
 --
 J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)