Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On 12/7/18 3:13 PM, Konstantin Belousov wrote: > 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 > 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//fd/ 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 ? I'm not sure. The motivating use case in some of the stuff I found online today was to permit one to construct a file with an initial set of contents such that other processes couldn't open the file until it was fully ready, so you created an unlinked file (Linux has an O_TMPFILE for this I think) and only later hooked it up in the filesystem. (You can use linkat with either /dev/fd/ or the /proc equivalent I think as the source to do this on Linux apparently.) I'm not sure it is otherwise useful. This particular use case also seems like a kludge to workaround the advisory file locking in POSIX, and you could also accomplish this by just doing a rename() from a temporary name to the final name instead. A use case I had in the past was a helper application that wanted to avoid races with trying to execute binaries over NFS, so it would copy the binary to local disk and fork a child to call exec. Once the child exec'd it would unlink the binary so they didn't leak on the local filesystem. However, it would also watch the child process and if the child process crashed instead of exiting cleanly it would make a new copy of the binary (by reading from the original and writing it out to a new file) so that there was a matching binary for the core that could be used with a debugger. In theory flink() would have been more efficient than making a copy of the file. OTOH, that was also running as an unprivileged user and flink() for non-root user, so if the previous security concerns are still valid I think you probably don't want non-root using flink(). -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
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 > >>> 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//fd/ 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On Fri, Dec 07, 2018 at 11:34:50AM -0800, John Baldwin wrote: > On 12/7/18 10:59 AM, Conrad Meyer wrote: > > On Fri, Dec 7, 2018 at 10:05 AM John Baldwin wrote: > >> 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. > > > > None of these syscalls were added to sys/kern/capabilities.conf, so I > > think a capsicum-contained root cannot use them anyway. Maybe I > > misunderstand how capabilities.conf works, though. > > Ok. FWIW fhopenat(2) was added to capabilities.conf in the original submission. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On 12/7/18 10:59 AM, Conrad Meyer wrote: > On Fri, Dec 7, 2018 at 10:05 AM John Baldwin wrote: >> 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. > > None of these syscalls were added to sys/kern/capabilities.conf, so I > think a capsicum-contained root cannot use them anyway. Maybe I > misunderstand how capabilities.conf works, though. Ok. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On Fri, Dec 7, 2018 at 10:05 AM John Baldwin wrote: > 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. None of these syscalls were added to sys/kern/capabilities.conf, so I think a capsicum-contained root cannot use them anyway. Maybe I misunderstand how capabilities.conf works, though. Best, Conrad ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
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 >>> 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//fd/ 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
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 > > 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
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 > 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. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
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
Sponsored by: Gandi.net
Tested by:pho
Feedback from:brooks, markj
MFC after:1 week
Differential revision:https://reviews.freebsd.org/D18359
Added:
head/lib/libc/sys/fhlink.2 (contents, props changed)
head/lib/libc/sys/fhreadlink.2 (contents, props changed)
Modified:
head/lib/libc/sys/Makefile.inc
head/lib/libc/sys/Symbol.map
head/lib/libc/sys/getfh.2
head/sys/compat/freebsd32/syscalls.master
head/sys/kern/syscalls.master
head/sys/kern/vfs_syscalls.c
head/sys/sys/mount.h
Modified: head/lib/libc/sys/Makefile.inc
==
--- head/lib/libc/sys/Makefile.inc Fri Dec 7 14:45:28 2018
(r341688)
+++ head/lib/libc/sys/Makefile.inc Fri Dec 7 15:17:29 2018
(r341689)
@@ -184,7 +184,9 @@ MAN+= abort2.2 \
extattr_get_file.2 \
fcntl.2 \
ffclock.2 \
+ fhlink.2 \
fhopen.2 \
+ fhreadlink.2 \
flock.2 \
fork.2 \
fsync.2 \
@@ -395,7 +397,8 @@ MLINKS+=ffclock.2 ffclock_getcounter.2 \
MLINKS+=fhopen.2 fhstat.2 fhopen.2 fhstatfs.2
MLINKS+=fsync.2 fdatasync.2
MLINKS+=getdirentries.2 getdents.2
-MLINKS+=getfh.2 lgetfh.2
+MLINKS+=getfh.2 lgetfh.2 \
+ getfh.2 getfhat.2
MLINKS+=getgid.2 getegid.2
MLINKS+=getitimer.2 setitimer.2
MLINKS+=getlogin.2 getlogin_r.3
Modified: head/lib/libc/sys/Symbol.map
==
--- head/lib/libc/sys/Symbol.mapFri Dec 7 14:45:28 2018
(r341688)
+++ head/lib/libc/sys/Symbol.mapFri Dec 7 15:17:29 2018
(r341689)
@@ -401,6 +401,13 @@ FBSD_1.5 {
cpuset_setdomain;
};
+FBSD_1.6 {
+ fhlink;
+ fhlinkat;
+ fhreadlink;
+ getfhat;
+};
+
FBSDprivate_1.0 {
___acl_aclcheck_fd;
__sys___acl_aclcheck_fd;
Added: head/lib/libc/sys/fhlink.2
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libc/sys/fhlink.2 Fri Dec 7 15:17:29 2018(r341689)
@@ -0,0 +1,268 @@
+.\" SPDX-License-Identifier: BSD-2-Clause
+.\"
+.\" Copyright (c) 2018 Gandi
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd November 29, 2018
+.Dt FHLINK 2
+.Os
+.Sh NAME
+.Nm fhlink ,
+.Nm fhlinkat
+.Nd make a hard file link
+.Sh LIBRARY
+.Lb libc
+.Sh SYNOPSIS
+.In unistd.h
+.Ft int
+.Fn fhlink "fhandle_t *fhp" "const char *to"
+.Ft int
+.Fn fhlinkat "fhandle_t *fhp" "int tofd" "const char *to"
+.Fc
+.Sh DESCRIPTION
+The
+.Fn fhlink
+system call
+atomically creates the specified directory entry (hard link)
+.Fa to
+with the attributes of the underlying object pointed at by
+.Fa fhp .
+If the link is successful: the link count of the underlying object
+is incremented;
+.Fa fhp
+and
+.Fa to
+share equal access and rights
+to the
+underlying object.
+.Pp
+If
+.Fa fhp
+is removed, the file
+.Fa to
+is not deleted and the link count of the
+underlying object is
+decremented.
+.Pp
+The object pointed at by the
+.Fa fhp
+argument
+must exist for the hard link to
+succeed and
+both
+.Fa fhp
+and
+.Fa to
+must be in the same file system.
+The
+.Fa fhp
+argument
+may not be a directory.
+.Pp
+The
+.Fn fhlinkat
+system call is equivalent to
+.Fa fhlink
+except in
