From owner-svn-src-all@freebsd.org Fri Dec 7 23:31:11 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 1BF6D1323BB1; Fri, 7 Dec 2018 23:31:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 883157CE9E; Fri, 7 Dec 2018 23:31:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 675D510B68A; Fri, 7 Dec 2018 18:31:08 -0500 (EST) Subject: Re: svn commit: r341689 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys To: Konstantin Belousov References: <201812071517.wB7FHTiI035911@repo.freebsd.org> <20181207174757.GI52540@kib.kiev.ua> <20181207231326.GK52540@kib.kiev.ua> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= xsDiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg80eSm9obiBCYWxk d2luIDxqb2huQGJhbGR3aW4uY3g+wmMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX gAUCRND5wwIZAQAKCRBy3lIGd+N/BNLXAJ9KIb6teuDL1W+FkCgvv+y8PxKTkACeIUfbn3sl cueBzqTcf09idwa8YTbOwU0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Ds gnr31AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh +GojXlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cM SOrHYUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOF QVHOEVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq 1tqzhltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZ TwtXsNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m 7Z164yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioI AjjHaIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbU KWwxQ4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjH uW/CSQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZN wwCfafMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <791d6d0c-671f-d4cd-272c-2d7e89f9f849@FreeBSD.org> Date: Fri, 7 Dec 2018 15:31:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181207231326.GK52540@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 07 Dec 2018 18:31:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-Rspamd-Queue-Id: 883157CE9E X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] 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:31:11 -0000 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