Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html