From owner-svn-src-projects@freebsd.org Tue May 7 15:03:40 2019 Return-Path: Delivered-To: svn-src-projects@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 5C2731589F40 for ; Tue, 7 May 2019 15:03:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A47348CB27; Tue, 7 May 2019 15:03:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f67.google.com with SMTP id x132so1187795lfd.0; Tue, 07 May 2019 08:03:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hGnhLfl3lO3TnDKHVw8MUX1UGALDa5Vzk4R4N5Hpfjk=; b=OOElGnuINJ7p43O5+9ZQDxhN49GFziy5auF+TTh6hd1Qs0c1IyBBVo89VKLy0CFfIU fTq3faLbOsOIVDoSW99ZIeiorwCUR87J8BgS2+uFSMyAsSvsr2Xom8nXO2Nh3qNEvr45 eL8xwBOlPxK2bBTsFu8N73VmgPBYaTcEMS5aHchminI5ctB5yBo+9/O4/Btj5GQ4Ny/X 2BVDExfqh+fYlgYDVwZABALprPoCjGckyrgpqUKQM6Cgdu8bgnkplMELL1xGxSDcDVQM cZQdb6nDf24qiNmUVgtwwM+GYTstXZFlckz6nnKdEZm6/3oG/wsot/DiKFz5E9gOnxUu 3bfQ== X-Gm-Message-State: APjAAAUvO2+CWNPaM6lG9cYBn+aZXOhRPylExECb3xbmnIWrUseyfZiv 2/Jc70jO7dcsSLTROP5Y+gFLU1mMmeLwz2jXaUU= X-Google-Smtp-Source: APXvYqw/EX9byfvhAlGnG2/I9saSHkNDQ6yfvw7pQYbSym1fyShgrznF/YpJr+OPR0QeBU8rpsLuYgV1DhG42ZTvgpk= X-Received: by 2002:ac2:4301:: with SMTP id l1mr17831943lfh.54.1557241413356; Tue, 07 May 2019 08:03:33 -0700 (PDT) MIME-Version: 1.0 References: <201905070127.x471ROvf000119@repo.freebsd.org> <20190507231529.I1127@besplex.bde.org> In-Reply-To: <20190507231529.I1127@besplex.bde.org> From: Alan Somers Date: Tue, 7 May 2019 09:03:21 -0600 Message-ID: Subject: Re: svn commit: r347217 - in projects/fuse2: sys/fs/fuse tests/sys/fs/fusefs To: Bruce Evans Cc: src-committers , svn-src-projects@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A47348CB27 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:03:40 -0000 On Tue, May 7, 2019 at 8:18 AM Bruce Evans wrote: > > On Tue, 7 May 2019, Alan Somers wrote: > > > Log: > > fusefs: allow the null chown and null chgrp > > > > Even an unprivileged user should be able to chown a file to its current > > owner, or chgrp it to its current group. Those are no-ops. > > ffs allows this too, but POSIX seems to require appropriate privilege > even for null changes. Its DESCRIPTION section says "Changing the > user ID is restricted to processes with appropriate privileges." It > doesn't formally define "Changing", so this can be read as not > restricting null changes. However, its ERRORS section says that chown() > shall fail with errno [EPERM] if the euid doesn't match the owner of > the file or the calling process doesn't have appropriate privilege > (note: nothing about the null change where only the new and old owners > of the file match). Yeah, I was trying to satisfy pjdfstest, which expects the behavior of UFS. Do you think we should disallow the null change? If so we should do it for all file systems, not just fusefs. > > Most other attribute-setting syscalls don't allow null changes without > appropriate privilege. E.g., in ffs: > - chflags() requires VADMIN privilege > - truncate() requires write privilege (this seems to be only checked for > at the vfs level, where the nullness of a truncation is not easy to > determine) > - utimes() and friends require VDMIN privilege or write privilege to set > the current time (with the same layering as for truncate(), so is hard > to change) But utimensat allows the null change without privileges, because it has an explicit way to specify the null change: UTIME_OMIT. > - chmod() requires VDMIN privilege according to the comment, but VWRITE_ACL > privilege according to the code. > > Ownership and other attributes are also hard to handle for file systems > that don't support them. I only care about this for msdosfs. msdosfs > has fake file ids, but can have only 1 uid per file amd this often doesn't > match the euid, and even root can't change it. File ids are also used > for VADMIN checks, so tend to cause failures to set even unimportant > attributes like file times when the setting is possible. But some > impossible settings are silently ignored or silently adjusted to possible > settings. E.g., for file times, most successful settings lose precision. > > Ownership and other attributes are even harder to handle for file systems > that have more of them than vfs supports. Even for msdosfs, many attributes > were not reflected in file flags until a few years ago, and file times for > directories are still broken (by reading and writing the times to the wrong > alias -- the "." entry -- in msdosfs. Only msdosfs finds times there, and > msdosfs doesn't find times from the correct alias). ACLs are too complicated > for me, even without the problem of translating them. > > fuse has the larger problem of having to implement identical mishandling > of attributes for all file systems that it supports. > > Bruce