NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/51595: inconsistent behaviour in statvfs

>Number:         51595
>Category:       kern
>Synopsis:       inconsistent behaviour in statvfs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 03 13:25:00 +0000 2016
>Originator:     Thomas Klausner
>Release:        NetBSD 7.99.42
Curiosity is the very basis of education and if you tell me that 
curiosity killed the cat, I say only that the cat died nobly.
- Arnold Edinborough
Architecture: x86_64
Machine: amd64
In PR 42484 I reported a problem that I originally thought was caused by
tmpfs. With debugging help from hannken@ we found out that the issue stems
from the sandbox setup, in particular:

My pbulk sandboxes are below /archive/sandboxes, which has permissions
drwxr-x---  9 root  wheel  512 Aug 28 23:36 /archive/sandboxes

The problems seem to appear when the pbulk user (which is not a
member of wheel) inside a chroot calls statvfs.

kern/vfs_getcwd.c::getcwd_common() has inconsistent behaviour
when called without "flags & GETCWD_CHECK_ACCESS".

In that case, the directory permissions are only checked when
the entry is not in the cache.

hannken suggested a patch:
Index: kern/vfs_getcwd.c
RCS file: /cvsroot/src/sys/kern/vfs_getcwd.c,v
retrieving revision 1.50
diff -p -u -2 -r1.50 vfs_getcwd.c
--- kern/vfs_getcwd.c   7 Feb 2014 15:29:22 -0000       1.50
+++ kern/vfs_getcwd.c   31 Oct 2016 17:04:02 -0000
@@ -128,5 +128,5 @@ getcwd_scandir(struct vnode **lvpp, stru
        cn.cn_nameiop = LOOKUP;
        cn.cn_flags = ISLASTCN | ISDOTDOT | RDONLY;
-       cn.cn_cred = cred;
+       cn.cn_cred = NOCRED;
        cn.cn_nameptr = "..";
        cn.cn_namelen = 2;
Index: miscfs/genfs/genfs_vnops.c
RCS file: /cvsroot/src/sys/miscfs/genfs/genfs_vnops.c,v
retrieving revision 1.192
diff -p -u -2 -r1.192 genfs_vnops.c
--- miscfs/genfs/genfs_vnops.c  24 Mar 2014 13:42:40 -0000      1.192
+++ miscfs/genfs/genfs_vnops.c  31 Oct 2016 17:04:02 -0000
@@ -666,4 +666,8 @@ genfs_can_access(enum vtype type, mode_t
        int error, ismember;

+       /* Short-circuit requests coming from the kernel. */
+       if (cred == NOCRED || cred == FSCRED)
+               return 0;
        mask = 0;

but this breaks nfs:

panic: kernel diagnostic assertion "cred != NOCRED" failed: file "/usr/src/sys/kern/kern_auth.c", line 405
cpu7: Begin traceback...
vpanic() at netbsd:vpanic+0x140
cd_play_msf() at netbsd:cd_play_msf
kauth_cred_ngroups() at netbsd:kauth_cred_ngroups+0x83
nfs_request() at netbsd:nfs_request+0x1da
nfs_lookup() at netbsd:nfs_lookup+0x41c
VOP_LOOKUP() at netbsd:VOP_LOOKUP+0xa8
getcwd_scandir() at netbsd:getcwd_scandir+0x9f
getcwd_common() at netbsd:getcwd_common+0x213
sys___getcwd() at netbsd:sys___getcwd+0xaf
syscall() at netbsd:syscall+0x15b
--- syscall (number 296) ---
cpu7: End traceback...

since nfs needs a valid user for permissions checking on the server.

Have a chroot below a path that is not readable by a user, build
packages as that user, wait for a combination of effects to meet up.
(quite reliably happens for me in a libreoffice and/or firefox bulk
Possibly: save the prefix of the chroot in 'struct cwdinfo'

Workaround: allow the user permissions on all parts of the path
outside the chroot.


Home | Main Index | Thread Index | Old Index