Date: Fri, 7 Dec 2018 10:04:51 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <f88691bd-0efb-e49d-8486-1405c5eb11dc@FreeBSD.org> In-Reply-To: <20181207174757.GI52540@kib.kiev.ua> References: <201812071517.wB7FHTiI035911@repo.freebsd.org> <e9e457ed-00f5-705e-55ea-1ad602f34ef0@FreeBSD.org> <20181207174757.GI52540@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f88691bd-0efb-e49d-8486-1405c5eb11dc>