Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] really odd GCC bug? under Ubuntu



On Sat, May 11, 2013 at 01:50:39PM -0400, Richard Pieri wrote:
> Bill Bogstad wrote:
> > # chmod 0 /usr/local
> 
> Yeah, that doesn't do what you think it does.  It makes /usr/local
> unreadable but it doesn't make /usr/local/bin unreadable. 

HUH?  Yes, it does.  chmod 0 = chmod 0000.  No permissions to that
directory or anything under it.  You can't get past that unless you're
root (or equivalent), no matter what the permissions of things under
that are.  Even if you own the directory (unless of course you change
the permissions).

> It's the way that execute and read permissions on directories interact.

No, it isn't... not if the perms are 0.

You're confusing this with making a directory executable, but not
readable, and/or making a file executable, but not readable.  In the
former case, you can execute programs in the directory, and you can cd
into it, but you can not list the contents of it.  In the latter case,
you can excecute binary programs, but not scripts (which require read
access as the interpreter--which runs with the user's permissions, not
the kernel's--must read them).  You can not open such a file for
read.  Conversely, the case of read but not execute is obvious for
files, and for dirs you can list the contents of the dir but not cd
into it or execute files in it.

If perms of 0 did not restrict ALL access to a directory and
everything under it, then securing a unix file system would be
exceedingly tedious and error prone.  It behaves this way, because it
MUST, practically speaking.

> Things get weird if you remove one but not the other from a directory.

No, they don't.  The behavior (though a bit esoteric) is
well-documented and consistent across POSIX-compliant Unix flavors,
and to the best of my knowledge has not changed in at least 20 years,
and AFAIK ever, possibly excepting non-compliant oddball Unix
variants.

> When you remove both, well, behavior isn't consistent across different
> Unixes and Linux kernels. 

Yes, it is.  You will get EACCESS (permission denied).  On every
version of Linux, and every Unix that complies to POSIX.  And AFAIK,
every mainstream version of Unix that existed before that.  

It's possible some of the subtle details (like whether or not you can
stat() a file in a directory, depending on whether r or x is set on
the directory) have changed (though I don't believe so, I believe
execute has always been required for stat()), but in practice those
details are not relevant to this discussion, except perhaps for those
interested in historical trivia.  They don't affect any of the
behavior I described above.

-- 
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.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org