Re: kern/56316: vn_open doesn't follow symlinks

[Frank Kardel <kardel%netbsd.org@localhost>]

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

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56316: vn_open doesn't follow symlinks
Date: Sun, 18 Jul 2021 08:25:56 +0200

 Seconded.
 
 Seems the NOFOLLOW usage was in there before (with no effect, though) 
 that's why symlinks did work before.
 
 See also
 
 http://mail-index.netbsd.org/source-changes-d/2021/07/16/msg013394.html
 
 http://mail-index.netbsd.org/source-changes-d/2021/07/16/msg013395.html
 
 We should just disable the force setting of O_NOFOLLOW in vnopen and 
 check callers
 
 for correct O_NOFOLLOW usage.
 
 Frank
 
 
 On 07/18/21 08:10, mlelstv%serpens.de@localhost wrote:
 >> 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:
 >   	
 >