[was: Re: [Cooker] Royally messed up file permissions! (was: file command
has b0rked permissions on magic files)]
On Wed, 24 Apr 2002 16:04:10 -0400 I wrote:
<SIGH> OK... it's high time I get this permissions thingy sorted out
after various UNIX flavors, Apollo Domain, MINIX, Linux...
Is there a link to a *clear* set of file permission rules...? Google
doesn't help much...
So, as penance for my *stupid* analysis, here is a correction of my post
last night... I hope it keeps someone else from similar public
humiliation.
Checking some books...
O'Reily System Administration, 2nd ed. P.28, Table 2-2 reads:
[minor edits for readability]
Minimum Access Needed
Command (on file) (on dir. file is in)
-------------------- -------- --------
cd /home/chavez N/A x
ls /home/chavez/*.c none r
ls -s /home/chavez/*.c none rx
cat runme r x
cat >> runme w x
runme (binary) x x
runme (script) rx x
rm runme none xw
This is a consise table where everything makes so much more sense when
viewed with a more experienced eye; early attempts at understanding
produced an "I *know* that..." attitude. Proves you're never too old or
experienced to discover your understanding of a [simple] subject is
incomplete...
So...
> On 24 Apr 2002 12:56:55 -0500 Steve Fox <[EMAIL PROTECTED]> wrote:
>
> > Ok, my problems are spreading to other directories now. (so this has
> > nothing to do with the file command, that's just the first place I
> > noticed it).
> >
> > I'm trying to recompile Galeon, but I hit this error:
> >
> > configure:6963:21: /usr/include/gtk-1.2/gtk/gtk.h: Permission denied
> >
> > [drfickle@tp drfickle]$ ll /usr/include/gtk-1.2/
> > ls: /usr/include/gtk-1.2/gdk: Permission denied
> > ls: /usr/include/gtk-1.2/gtk: Permission denied
OK... this is acceptable if "x" is not set on /usr/include/gtk-1.2
> > [drfickle@tp drfickle]$ ll -d /usr/include/gtk-1.2/
> > drwxr-xr-x 4 root root 96 Feb 27 10:05
> > /usr/include/gtk-1.2//
But it is...
> > [drfickle@tp drfickle]$ ll -d /usr/include/
> > drwxr-xr-x 120 root root 17344 Apr 24 08:28 /usr/include//
> > [drfickle@tp drfickle]$ ll -d /usr/
> > drwxr-xr-x 16 root root 416 Feb 27 09:57 /usr//
> > [drfickle@tp drfickle]$ ll -d /
> > drwxr-xr-x 18 root adm 568 Apr 9 21:23 //
So *why* did the initial command fail..? (unresolved)
> > All the directories up to this point have global read and execute
> > permissions, so something has gone totally crazy.
> Yikes!!! This is FREAKY! and smelling like a kernel bug that's been
> around for a while...
Gotta quit going into fuzzy stuff when *my* thinking is not totally clear.
"kernel bug" in my head... Mea culpa!
...and now, the *penance*... Please correct any errors...
> Any chance you have symlinks involved...? They are in my case...
They do confuse the issue. Later...
> Anyone know of a utility to look at ALL directory bits (even unused
> ones) on disk? (see analysis below)
Never mind... (except for Steve's problem above)
----------------------------------
revised
> Here's my analysis so far...
^
In the following, ---, --x, ..., rwx are obvious;
* means "don't care";
***/*** refers to {path,dir}/{file,dir}
Here we go...
$ cd /home/chavez
**x Just do it!
**- Denied
While cd doesn't actually execute anything within the dir
(AFAIK), no subsequent command could; so no point cd'ing
$ ls /home/chavez
r** list filenames ONLY (Important point!)
r*x list filename properties
$ ls -l /home/chavez/
r*-/**- ls: /home/chavez/fileA: Permission denied
ls is allowed to see & list the filename; but without "x"
cannot display content *properties* of /chavez/*
This is what is denied.
$ ls *
**x/**- permitted for file; denied for dir. contents
**x/**x permitted
$ ls -l *
-*x/**- permitted for files; denied for dir. content properties
r*x/**x permitted for files and dir. content properties
Just because a user owns something doesn't mean s/he has full access to
it.
---------------------- back to my mental bug...
> Stranger yet... the above examples are really symlinked, like this:
> real path: /home/httpd/html/pfortin.org/Family
> symlink1: /var/www -> /home/httpd
> symlink2: /home/apache/pfortin.org -> /var/www/html/pfortin.org
"A picture is worth a 1000 words" -- except in ASCII art :^)
/ (d755.root.root)
:
:-- var (d755.root.root)
: :
: :-- www (l777.root.root) >-----------.
: |
:-- home (d755.root.root) |
: |
: |
: |
:-- httpd (d700.apache.nogroup) |
: : <---------------------------'
: :
: :-- html (d755.apache.nogroup)
: :
: :-- pfortin.org (d755.apache.apache)
: : :
: : :-- Family (d755.apache.apache)
: : :
: : :-- 2 (d755.apache.apache)
: :-- new.pfortin.org (d755.apache.apache)
: .---> :
: | :-- Family (d755.apache.apache) [1]
: | :
: | :-- 2 (d644.apache.apache) [2]
: \________________________________
: |
:-- apache (d755.apache.apache) |
: : |
: :-- pfortin.org (l777.apache.apache) >---'
[1] - this dir. was 644 last night
[2] - *should* be 755
For those paying close attention:
> symlink2: /home/apache/pfortin.org -> /var/www/html/pfortin.org
*should* have read:
> symlink2: /home/apache/pfortin.org -> /var/www/html/new.pfortin.org
I *thought* I had this all straight when I setup my web sites (see
http://pfortin.com/Linux/WWW)
[snipped gibberish]
> There are many directories in ...pfortin.org; but "Family" is the only
> one with this problem.
Actually, it was Family in [new.]pfortin.org -- which gets rsync'ed to
pfortin.org...
> Now... all these are owned by apache.apache and if I try "ls" on the
> ones which go through symlinks, I see the problem; but ls on the *real*
> path works:
> $ ls /home/httpd/html/pfortin.org/Family
> 1/ 2/ 4/ 6/ 8/ copyright.shtml index.shtml.bak
> 10/ 3/ 5/ 7/ 9/ index.shtml
Duh! cuz it was NOT /home/httpd/html/new.pfortin.org/Family
^^^^
which I had altered; but not yet rsync'ed to
/home/httpd/html/pfortin.org/Family
> Gory details:
[snip]
> Anyone know of a utility to look at the directory contents on disk?
s/disk/brain/ :^P
> > Please let me know what other information I can send to help diagnose
> > this.
>
> Ditto...
Thanks all, for letting me step back into this steaming pile rather than
shoving my head into it...
Hanging head in shame, and hoping I finally got it right...
Pierre
PS: Steve, apologies for de-railing your post.
