kern/56316: vn_open doesn't follow symlinks

[mlelstv%serpens.de@localhost]

>Number:         56316
>Category:       kern
>Synopsis:       vn_pen doesn't follow symlinks
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 18 06:10:00 +0000 2021
>Originator:     Michael van Elst
>Release:        NetBSD 9.99.86
>Organization:
	
>Environment:
	
	
System: NetBSD tazz 9.99.86 NetBSD 9.99.86 (GENERIC) #56: Sat Jul 17 12:57:46 UTC 2021 mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

The kernel function vn_open() is used to easily open filesystem paths to be used by other
kernel subsystems.

The common usage would be:
	
	struct pathbuf *pb;
	struct nameidata nd;

	NDINIT(&nd, op, nmode, pb);
	error = vn_open(&nd, fmode, cmode);

if nmode included FOLLOW or fmode did not include O_NONFOLLOW, then
namei will follow symlinks.

After the recent change the common usage pattern was changed to:

	struct pathbuf *pb;

	error = vn_open(NULL, pb, nmode, fmode, cmode, &vp, NULL, NULL);

Again, if nmode included FOLLOW or fmode did not include O_NONFOLLOW,
then namei will follow symlinks... according to the code. But the comment
above vn_open denotes:

 * Note that callers that want NOFOLLOW should pass O_NOFOLLOW in fmode,
 * not NOFOLLOW in nmode.

Passing NOFOLLOW however does nothing, it's a "flag" with value zero
and only acts like a placeholder. So if you move NOFOLLOW (a nop)
to O_NOFOLLOW you never resolve symlinks.

That's what currently prevents ZFS from accessing disks via symlinks
where the code was changed according to the comment but not according
to what the code does.

>How-To-Repeat:
zpool create mypool /dev/wedges/abcdef

where /dev/wedges/abcdef is a symlink to some /dev/dkN

>Fix:
	

>Unformatted: