From owner-svn-src-head@freebsd.org Fri Dec 7 17:48:09 2018 Return-Path: Delivered-To: svn-src-head@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 7E3901314EE5; Fri, 7 Dec 2018 17:48:09 +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 85B9A6FF87; Fri, 7 Dec 2018 17:48:08 +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 wB7Hlvhf092391 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Dec 2018 19:48:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wB7Hlvhf092391 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wB7HlvGA092390; Fri, 7 Dec 2018 19:47:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 7 Dec 2018 19:47:57 +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: <20181207174757.GI52540@kib.kiev.ua> References: <201812071517.wB7FHTiI035911@repo.freebsd.org> 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: 85B9A6FF87 X-Spamd-Result: default: False [-5.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,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.92)[-0.917,0]; IP_SCORE(-2.12)[ip: (-2.55), 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-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 17:48:09 -0000 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.