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

[Frank Kardel <kardel%kardel.name@localhost>]

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

From: Frank Kardel <kardel%kardel.name@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, mlelstv%serpens.de@localhost
Cc: 
Subject: Re: kern/56316: vn_open doesn't follow symlinks
Date: Sun, 18 Jul 2021 09:06:55 +0200

 Did you notice that zfs has a wrapper zfs_vn_open for vn_open in
 
 src/external/cddl/osnet/sys/sys/vnode.h?
 
 static inline int
 zfs_vn_open(const char *pnamep, enum uio_seg seg, int filemode, int 
 createmode,
      vnode_t **vpp, enum create crwhy, mode_t umask)
 {
          struct pathbuf *pb;
          int error;
 
          ASSERT(seg == UIO_SYSSPACE);
          ASSERT((filemode & (FWRITE | FCREAT | FTRUNC | FOFFMAX)) != 0);
          ASSERT(crwhy == CRCREAT);
          ASSERT(umask == 0);
 
          "
 
          pb = pathbuf_create(pnamep);
          error = vn_open(NULL, pb, 0, filemode, createmode, vpp, NULL, 
 NULL);
          if (error == 0) {
                  VOP_UNLOCK(*vpp, 0);
          }
          pathbuf_destroy(pb);
          return (error);
 }
 
 There is is forced.
 
 Removing "filemode |= O_NOFOLLOW;" there makes ZFS opening devices via 
 symlinks again.
 
 Frank
 
 On 07/18/21 08:55, Michael van Elst wrote:
 > The following reply was made to PR kern/56316; it has been noted by GNATS.
 >
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/56316: vn_open doesn't follow symlinks
 > Date: Sun, 18 Jul 2021 06:51:48 -0000 (UTC)
 >
 >   kardel%netbsd.org@localhost (Frank Kardel) writes:
 >   
 >   > We should just disable the force setting of O_NOFOLLOW in vnopen and
 >   
 >   It's not forced. Apparently just in the ZFS case the caller was changed
 >   to set O_NOFOLLOW and there is confusion on what FOLLOW and NOFOLLOW
 >   do. In fact, both are and were masked inside vn_open, so the O_NOFOLLOW
 >   flag is and has been the only relevant (despite what the comment said).
 >   
 >