I think I covered the items you requested. I'm not very experienced with phabricator. Please let me know if I'm doing things wrong. I switched from AUE_OPENAT2 to AUE_OPENAT, but am not sure what is expected here regarding auditing. AUE_NULL is obviously wrong since it would provide an unaudited way to open files. Do I commit with AUE_OPENAT, then apply to get formal AUE_OPENAT2, then make another revision to update the auditing?

This diff should address review received and contain reference implementation of handling for openat2 resolve flags. I'm happy to remove from this diff if you prefer for implementation to be handled in different commit.

My current plan is to map the openat2 resolve flags into new ones that can be passed into vn_open_cred() as additional vn_open_flags and then mapped to relevant namei flags in open2nameif(), but am very much open to suggestions about how you want to do this properly.

Diff adding new openat2 system call is here: https://reviews.freebsd.org/D43390

Per feedback, this reverts syscall-related changes and restores original diff. Will create new diff for syscall.

In D43313#988667, @kib wrote:

Please

1. Move addition of the open2 syscall into a new review.
2. Do not put changes to generated files into the diff (it should be committed as an additional commit anyway).
3. I very much dislike internal openat flag. Please add a new flag2 argument for kern_openat(9) (and perhaps vn_open_cred() but might be not needed right now) and pass a new flag there.

In D43313#987766, @mjg wrote:

Linux folk explicitly designed openat2 to be extensible, so I expect it is going to pick up explicit "official" usage down the road.

That said, I think a minimal initial implementation is the way to go here.

Add openat2() syscall that wraps around kern_openat.

I can possibly submit a minimal openat2() implementation that only supports existing resolve flags for now (for example: RESOLVE_BENEATH, RESOLVE_NO_SYMLINK) if decision is firm that we don't want to add more path-resolution flags for open(2).

In D43313#987356, @kib wrote:

open(2) should be updated to describe the flag. Probably additional text explaining the difference with O_NOFOLLOW would be useful as well.

Does the same flag needed for *at() syscalls?

In D43313#987417, @mjg wrote:

sounds like the thing to do is to add openat2 so that this automagically works, instead of a freebsd-specific flag

Remove unused variable

Fix undefined reference that crept in while applying suggested changes.

Thanks for the feedback Rick. I unfortunately don't have commit rights and someone else will have to do that for me.

After some discussion with Mav, I switched to initializing err_msg to NULL and resetting it after free() if we encounter an error. Removed now-unused variable.

Moved statfs check to different function. Updated comments. Initialized err_msg to NULL on each loop iteration.

For reference purpose, here is a link to the WIP Samba development branch where I'm working this issue: https://gitlab.com/samba-team/devel/samba/-/commits/anodos325-add-fdescfs-proc-fd-path-plumbing
overall strategy is:

1. in source3/smbd/open.c convert "pathref" struct files_struct to a non-pathref one through openat() with O_EMPTY_PATH.
2. in source3/lib/system.c we set up a "proc_fd pattern" for FreeBSD using fdescfs. (this is will be used by samba in cases where Linux-side uses /proc/self/fd/FD with path-based syscalls that aren't open().
3. write verbose enough log messages to guide admin to correct (for samba) fdescfs configuration.

Indeed. It works much better when I read and do the right thing :)

Okay. Still having issues with O_EMPTY_PATH for my minimal test case:

	int op, fd;
	op = open("/", O_DIRECTORY|O_PATH);
	if (op == -1) {
		printf("op failed: %s\n", strerror(errno));
	}

I have two distinct use-cases for the O_PATH descriptors:

1. "re-open" the O_PATH desc. This wasn't possible because fdescfs gives me the equivalent of dup2(). You propose to use openat() as follows int new_fd = openat(opath_fd, NULL, O_EMPTY_PATH); to do this?
2. be able to use path-based syscalls with a fdescfs path, e.g. chmod("/dev/fd/FD", 551);

I will defer to your judgment about what makes sense and works best from a kernel perspective. The issue you highlighted with re-evaluation of permissions on open may be a problem. I haven't checked what Linux does in this case.

Excellent. This provides exactly what we needed for samba. In addition to the issues reported about O_DIRECTORY on fdescfs, I can now do the following:

I haven't tried yet in Samba, wanted to cover basic syscall usage of it first. Timur hasn't ported Samba 4.14 to FreeBSD yet (hopefully soon). I'll try to find time tomorrow to build Samba 4.14 for testing purposes with this.

Latest revision looks good to me. I performed some basic tests with fstatat, utimesat, and friends with an O_PATH fd and everything seemed to work as expected.

acl_get_fd(fd): Invalid argument
futimens(fd): Invalid argument
extattr_set_fd(fd): Invalid argument

Okay. These now fail as expected. errno is EINVAL rather than EBADF. In case of futimens() Linux fails with EBADF.

I was also able to acl_set_fd_np() on the opath_fd when user has ACL_WRITE_ACL.

acl_t theacl = acl_get_fd(opath_fd);
if (theacl == NULL) {
        printf("XXX: acl_get_fd failed: %s\n", strerror(errno));
}
acl_t stripped = acl_strip_np(theacl, 0);
if (stripped == NULL) {
        printf("XXX: acl_strip_np() failed: %s\n", strerror(errno));
}
ret = acl_set_fd_np(opath_fd, stripped, ACL_TYPE_NFS4);
if (ret != 0) {
        printf("Failed to acl_set_fd_np(): %s\n", strerror(errno));
}
else {
        printf("Succeeded in setting ACL\n");
}

I'm not sure what the expectation is here regarding capabilities. I'm not sure whether Linux returns in this case are side-effect of design or implementation detail due to its vfs.
I like the idea of being able to extattr_list_fd(), extattr_get_fd(), acl_get_fd_np(), etc in addition to the short list in the Linux manpage for the O_PATH fd (this seems genuinely useful). But writing xattrs, changing ACLs, and changing timestamps probably shouldn't be possible.

I was successfully able to run extattr_set_fd(opath_fd, EXTATTR_NAMESPACE_USER, "thexattr", buf, sizeof(buf)); I believe this should fail with EBADF like fchmod() and the like.

Noticed one small difference so far:
On linux futimens(opath_fd, NULL) fails with EBADF. It's succeeding on FreeBSD (when permissions allow).

I suggest you to also take D29111 AT_EMPTY_PATH (it is probably required to get anything useful out of O_PATH).

But, can you test this implementation before it goes into the tree?

Samba usage of O_PATH is documented here: https://gitlab.com/samba-team/samba/-/blob/v4-14-stable/source3/modules/The_New_VFS.txt
The 4.14 branch (where it is used) is the current stable release. Adding support for O_PATH would be much appreciated.

Added context and basic regression test. Switched to using cwd for parent directory.

In D25593#566181, @brooks wrote:

Some general comments in no particular order:

• pathseg strikes me as over engineering. While trivial to implement the value is always the same.
• I'm a bit skeptical of the overall interface in particular the cnt argument. It does match setutimes but that interface is odd (and there doesn't appear to be any in-tree consumer of the numtimes > 2).
• A manpage would be required for commit.
• Please either don't include generated files or update to a version of FreeBSD that adds @generated to them so they don't show up in the diff.

Add context to diff