Re: [PATCH v4 2/2] interpret-trailers: add option for in-place editing

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 19, 2016, 20:58 UTC
Message-ID: <xmqqfuxt9ti3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAPig+cRozqCKdC2+nyG-UM6xFo_sSqa7OhGgcycyyDQujZHtHA@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 6 quoted lines

> My understanding is that SANITY is an expectation that directory
> permissions work in an expected POSIXy way: that is, a file can't be
> deleted when its containing directory lacks 'write', and a file can't
> be read/accessed when the directory has neither 'read' nor 'execute'.
> This doesn't say anything about root not being allowed to read a file
> when the file itself lacks 'read'.

In short, SANITY is "does looking at permission bits sufficient to anticipate what the filesystem would do?" while POSIXPERM is "can chmod be used to tweak permission bits of the filesystem" (a filesystem that lacks permission bits support would qualify as !POSIXPERM, as there is nothing to tweak in the first place).

I suspect the comment added by f400e51c and its patch description stressed too much about permission of a directory affecting what we can do to files inside the directory, and failed to describe another criteria for a sane environment: "files whose permission bits say you shouldn't be able to read or write cannot be read or written". Traditionally, running tests as root was one major way to break SANITY, but as f400e51c noticed, "can we write to '/'?", which was an old-fashioned way to catch the only case where SANITY does not hold on POSIX systems [*1*], cannot catch insanity on non-POSIX system like Cygwin.

POSIXPERM is more about "if we do chmod, does filesystem remember it so that ls -l reports the same?" Output from "git grep POSIXPERM t" shows that some users of it also assume that it requires "we can make something executable by doing chmod +x and unexecutable by doing chmod -x" (and that is fine--running tests as root would not make an unexecutable file executable). The tests that require POSIXPERM but not SANITY can be run by root (I am not saying that running tests as root is safe or sane, though) and are expected to produce the same result as they were run by a non-root user.

[Footnote]

*1* This is an old-fashioned way back when everybody on UNIX was
    sane and / had 0755 permission bits everywhere.  Some people
    make their / owned by sysadmin group and give 0775 bits, and
    "test -w /" would incorrectly say that the environment lacks
    SANITY when run by non-root users in the sysadmin group, even
    though our tests like "chmod -r file && ! cat file" (drop
    readable bit, expect it to become unreadable) guarded by SANITY
    can correctly run by them.

    Back when f400e51c was written, checking `whoami` was suggested
    as an alternative as a workaround for this "/ may be writable by
    a non-root person and not a good SANITY check" issue, but that
    was rejected because it obviously would not work on Cygwin.