From owner-svn-src-all@freebsd.org Fri Dec 7 23:13:38 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C27E13232FB; Fri, 7 Dec 2018 23:13:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 866877C0DA; Fri, 7 Dec 2018 23:13:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wB7NDQrS066388 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Dec 2018 01:13:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wB7NDQrS066388 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wB7NDQ5V066386; Sat, 8 Dec 2018 01:13:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Dec 2018 01:13:26 +0200 From: Konstantin Belousov To: John Baldwin 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> References: <201812071517.wB7FHTiI035911@repo.freebsd.org> <20181207174757.GI52540@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.0 (2018-11-25) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 866877C0DA X-Spamd-Result: default: False [-5.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.94)[-0.942,0]; IP_SCORE(-2.11)[ip: (-2.52), ipnet: 2001:470::/32(-4.48), asn: 6939(-3.47), country: US(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 23:13:38 -0000 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.