Date: Sat, 8 Dec 2018 01:13:26 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys Message-ID: <20181207231326.GK52540@kib.kiev.ua> In-Reply-To: <f88691bd-0efb-e49d-8486-1405c5eb11dc@FreeBSD.org> References: <201812071517.wB7FHTiI035911@repo.freebsd.org> <e9e457ed-00f5-705e-55ea-1ad602f34ef0@FreeBSD.org> <20181207174757.GI52540@kib.kiev.ua> <f88691bd-0efb-e49d-8486-1405c5eb11dc@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181207231326.GK52540>