Re: bin/52512: Duplicate files prevent veriexecctl from loading signature file

[Paul Goyette <paul%whooppee.com@localhost>]

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

From: Paul Goyette <paul%whooppee.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/52512: Duplicate files prevent veriexecctl from loading
 signature file
Date: Wed, 30 Aug 2017 07:43:22 +0800 (+08)

 > But you have a struct vnode *, so you should be able to do a vptofh?
 
 OK, I found the docs for VFS_VPTOFH().
 
 But I'm not sure how this is useful.  If I had the file handle of the
 original file, I could compare it with the file handle of the file being
 added.  But that (compare) would seem to be a file-system-specific
 operation, and it's not clear that any file system code provides a
 file-handle-compare capability.  And given that "The contents of the
 file handle are ... not examined by any other subsystems" it would seem
 inappropriate for veriexec to do its own compare.
 
 Further more, the docs strongly imply that file handles do not need to
 be supported by all file systems (in which case VFS_VPTOFH() returns
 EOPNOTSUPP).  (Of course, in this case I could always revert to current
 behavior and report the EEXIST error.)
 
 But this all seems moot to me, since the only info I have available for
 the original file entry is the veriexec_file_entry itself.
 
 /* Veriexec per-file entry data. */
 struct veriexec_file_entry {
          krwlock_t lock;                         /* r/w lock */
          u_char *filename;                       /* File name. */
          u_char type;                            /* Entry type. */
          u_char status;                          /* Evaluation status. */
          u_char *fp;                             /* Fingerprint. */
          struct veriexec_fpops *ops;             /* Fingerprint ops vector*/
          size_t filename_len;                    /* Length of filename. */
 };
 
 The filename member may or may not be populated (under control of a
 userland-specified flag "keep-filename" in the initial creation of the
 entry).  Even if it were available, the filename cannot be used for
 duplicate checking, since the whole reason we have a problem is that
 files can have multiple names.  :)
 
 So, to me at least, the following seems to be the most reliable way to
 check for and ignore duplicates:
 
          /*
           * If we already have an entry for this file, and it matches
           * the new entry exactly (except for the filename, which may
           * be hard-linked!), we just ignore the new entry.  If the
           * new entry differs, report the error.
           */
          if ((ovfe = veriexec_get(vp)) != NULL) {
                  error = EEXIST;
                  if (vfe->type == ovfe->type &&
                      vfe->status == ovfe->status &&
                      vfe->ops == ovfe->ops &&
                      memcmp(vfe->fp, ovfe->fp, vfe->ops->hash_len) == 0)
                          ignore_dup = true;
                  goto unlock_out;
          }
 
 
 
 +------------------+--------------------------+----------------------------+
 | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
 | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
 | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
 +------------------+--------------------------+----------------------------+