Project

General

Profile

Actions

Bug #14984

open

vnodetopath could be more reliable for files on ZFS

Added by Matt Barden about 1 year ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
kernel
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
fs_auditing
Gerrit CR:
External Bug:

Description

Today, vnodetopath() is able to reconstruct a path for directories with an empty v_path through successive '..' lookups. However, if a non-directory has an empty v_path, there is no way for the system to rediscover a valid v_path until someone comes along and re-opens the object by name. That's a common problem in NFS; once a client discovers the NFS File Handle for a particular file, it can use that handle to access the file until the file is deleted, including across server reboots or failover. The server maps the file handle to a vnode using VFS_VGET, which leaves its v_path untouched (meaning it's empty if it has never been accessed by name). That's a problem for NFS auditing (#11874), as the path is the only way for a human to reliably determine what file is being referenced in the audit trail. Other possible identifiers (NFS file handle, file inode, etc) can't be readily interpreted without access to the filesystem, and they can only be mapped real data if the object in question still exists.

It turns out that ZFS files track the object ID of their parent. This is used today for the obj_to_path IOCTL to create a dataset-relative pathname for a given objectID. This allows us to perform an equivalent to '..' lookups for non-directories in ZFS. We can use this to create a new VOP_IOCTL() command to find the parent vnode of any given ZFS object, even if it's not a directory, and then use this IOCTL in dirtopath() when the vnode in question is not a directory. That will make vnodetopath() more reliable for ZFS files.

Testing was done by accessing a file over an NFS mountpoint, exporting/importing the pool, and then re-accessing the file over NFS; the file should have a valid v_path.
'ls -l /proc/*/path' was ran to force procfs to call vnodetopath() on various objects on various filesystems.
Additionally, 'less' was used locally to keep a vnode open to files on various other filesystems (tmp, zfs, lofs). MDB was then used to set the vnode's v_path to vn_vpath_empty, and then 'ls -l /proc/<less pid>/path/4' was ran to force procfs to call vnodetopath() on the file.

This change significantly increases the reliability of NFS auditing. Without it, we face the tough choice of near-useless audit records (i.e. ones with an empty path), or the risk of interrupting applications (returning an error when we can't get a path), whenever a client attempts to access a vnode with an empty v_path.


Related issues

Blocks illumos gate - Feature #11875: ZFS changes for file access auditingNewMatt Barden

Actions
Actions #1

Updated by Electric Monk about 1 year ago

  • Gerrit CR set to 2362
Actions #2

Updated by Gordon Ross 9 months ago

  • Tags set to fs_auditing
Actions #3

Updated by Gordon Ross 9 months ago

Actions #4

Updated by Bill Sommerfeld 9 months ago

It turns out that ZFS files track the object ID of their parent.

What is the behavior when a single file is named by multiple directories so there isn't a single unambiguous parent?

To give one example of such packaged by illumos-gate, /usr/share/lib/zoneinfo/US/Eastern and /usr/share/lib/zoneinfo/America/New_York are two names for the same file; there are many such aliases packaged in system/data/zoneinfo.

Actions

Also available in: Atom PDF