On Fri, Dec 07, 2018 at 09:21:34AM -0800, John Baldwin wrote: > On 12/7/18 7:17 AM, Konstantin Belousov wrote: > > Author: kib > > Date: Fri Dec 7 15:17:29 2018 > > New Revision: 341689 > > URL: https://svnweb.freebsd.org/changeset/base/341689 > > > > Log: > > Add new file handle system calls. > > > > Namely, getfhat(2), fhlink(2), fhlinkat(2), fhreadlink(2). The > > syscalls are provided for a NFS userspace server (nfs-ganesha). > > > > Submitted by: Jack Halford <j...@gandi.net> > > Sponsored by: Gandi.net > > Tested by: pho > > Feedback from: brooks, markj > > MFC after: 1 week > > Differential revision: https://reviews.freebsd.org/D18359 > > Can this be used to implement 'flink' (create a link to an open file > descriptor)? Hmm, it appears so. It is limited to PRIV_VFS_GETFH at least. > The getfh(2) manpage notes this explicitly, but the new manpages don't > appear to. Even with the PRIV check, I'm still somewhat nervous about what > flink means for processes running as root that are using Capsicum. Maybe > it's ok, but I didn't see any discussion of this in the review.
If the process can execute getfh(2) and fhlink(2), then its privileges are not much different from the privileges of the in-kernel NFS server. During the review, I verified that PRIV_VFS_GETFH is checked, and considered suggesting fine-grainer individual privs for other operations, but decided that this is not too useful. That said, how can you translate from file descriptor to file handle ? E.g. to know (and not guess) the file handle on UFS, the process must posses PRIV_VFS_GENERATION. If you have PRIV_VFS_GETFH/PRIV_VFS_GENERATION privs, then you can implement flink(2) for UFS, but might be that it is even not undesirable. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
