svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Konstantin Belousov]

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 <jack at 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.