On Fri, Dec 07, 2018 at 10:04:51AM -0800, John Baldwin wrote: > On 12/7/18 9:47 AM, Konstantin Belousov wrote: > > 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. > > My understanding of the normal reason against flink is that you can make > unlinked files readable by other processes (though something like > /proc/<pid>/fd/<n> already permits this), and in particular if a more > privileged process passes an fd to a less privileged process. The > requirement for root mostly mitigates this when root vs not-root is your > only privilege. However, a capsicum vs non-capsicum process is a more > recent privilege that is orthogonal to root vs non-root. It might be that > allowing a capsicumized root to create links to files that were intentionally > unlinked by a non-capsicumized root would be the same problem. > > In practice on the majority of FreeBSD systems, root has all of the PRIV_foo > things. You have to write custom MAC modules to actually limit root. Thus > it would seem that we should now be happy to add flink() so long as it > requires root.
Do you think that flink(2) itself is useful ? As I understand the typical use case, it is the last chance way to recover of the unlinked but still opened file, by making a hard link from /dev/fd/N. _______________________________________________ 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"
