[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/56316: vn_open doesn't follow symlinks
The following reply was made to PR kern/56316; it has been noted by GNATS.
From: Frank Kardel <kardel%netbsd.org@localhost>
Subject: Re: kern/56316: vn_open doesn't follow symlinks
Date: Sun, 18 Jul 2021 08:25:56 +0200
Seems the NOFOLLOW usage was in there before (with no effect, though)
that's why symlinks did work before.
We should just disable the force setting of O_NOFOLLOW in vnopen and
for correct O_NOFOLLOW usage.
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
> 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
> 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.
> zpool create mypool /dev/wedges/abcdef
> where /dev/wedges/abcdef is a symlink to some /dev/dkN
Main Index |
Thread Index |