[Discuss] really odd GCC bug? under Ubuntu

[invalid at pizzashack.org (Derek Martin)]

On Mon, May 13, 2013 at 05:17:25PM -0400, Richard Pieri wrote:
> Derek Martin wrote:
> > Yes, it is.  You will get EACCESS (permission denied).  On every
> > version of Linux, and every Unix that complies to POSIX.
> 
> Few Unixes comply with POSIX. 

Virtually all of them do to some extent, and very much so on this
point.

> Not all file systems in the Linux kernel honor POSIX permissions
> (FAT). 

Irrelevant to the case we're discussing.  The default file system on
all Linux distros is ext*, all of which conform to standard Unix file
system semantics.  It was clear enough from context that Bill expected
standard Unix file system semantics to be in play, and it would be
extremely unusual to have /usr/local on something other than ext*, so
much so that a comment to that effect would absolutely be warranted if
it were the case.

> Some have had their behavior changed over the years either to fix
> exploitable bugs or to intentionally bring them in line with POSIX
> (ext2). Some use POSIX permissions in ways quite different from how
> POSIX defines them (AFS).

Irrelevant as above.

> All bets are off when ACLs are used.

Ditto.

> You'll get different behavior with elevated privileges which the Linux
> kernel has. 

I assume you mean capabilities.  I referred to this when I said "root
(or equivalent)."  Capabilities are by and large not used for file
system access by default on any Linux distro I'm familiar with, and
Bill gave no indication he was making use of them.  In other words,
irrelevant.

> It can see that there are files in a directory despite the
> permissions and ACLs. This is the cause of Bill experiencing things that
> weren't expected. 

NO, IT IS NOT.  If the files were not there, he would STILL get a
permission denied after chmod 0.  This conforms exactly to what I
said.

$ mkdir ddmtest
$ chmod 0 ddmtest
$ cat ddmtest/foo
cat: ddmtest/foo: Permission denied

> He can't see files if he changes the directory mode to
> 0, but the kernel can see them and it says "yep, there are files here"
> but then says "nope, you can't look at them". That's why mode 0 causes a
> permission denied error but a renamed directory causes no error at all.

NO, IT IS NOT.  The reason the renamed directory causes no error is
because the directory that gcc was looking for does not exist, and gcc
expects that to be possible.  Bill had adequate permissions on all
higher levels of the file system hierarchy (i.e. /usr) to be able to
distinguish that case from having inadequate permissions.  If you
write a C program to test this, you will get ENOENT in that case.  In
the case your directory exists and has perms 0, regardless of what
things look like under that, you will get EACCESS.  If you set /usr to
mode 0, suddenly you'll get the same perm denied as before, I promise
you.  As it has been, as long as I have been using Unix.  All of this
is 100% consistent with the behavior I described.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.