On Wednesday 24 April 2002 04:04 pm, Pierre Fortin wrote: > On 24 Apr 2002 12:56:55 -0500 Steve Fox <[EMAIL PROTECTED]> wrote: > > 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 > > [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// > > [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 //
This is bad.... > Yikes!!! This is FREAKY! and smelling like a kernel bug that's been > around for a while... Not likely. This actually looks a whole lot like possible hardware damage. If I was him, I'd use a drive scanner to check disk surface integrity. Doing a fsck on the disk won't catch it all the time in a hardware case. > Anyone know of a utility to look at ALL directory bits (even unused ones) > on disk? (see analysis below) none taht I know at the moment. > Here's my analysis so far... > > I'm getting ready to upgrade my LM8.1 server and I have a similar > situation on ext2... The owner has 644 perms and yet... [generic > summary]: > > $ cd somepath > bash: cd: somepath: Permission denied > > $ ls -ld somepath > drw-r--r-- 12 apache apache 4096 Apr 13 23:48 somepath/ > > $ ls somepath > ls: somepath/somefileA: Permission denied <== ??? > ls: somepath/somefileB: Permission denied <== ??? > somedir1/ somedir2 <== ??? > > ??? This would be a security issue if something wasn't broken; no contents > should be visible if the path permissions don't allow access... > > $ ls * # snipping all but "somepath" stuff leaves: > somedir1/ > somedir2/ > > $ ls somepath/somedir1 > ls: somepath/somedir1: Permission denied > > Here's how it got stranger yet... I copied the directory (as root) and > deleted "somepath"; then, a new directory created later took on these > strange properties... > > Stranger yet... the above examples are really symlinked, like this: > real path: /home/httpd/pfortin.org/Family > symlink1: /var/www -> /home/httpd > symlink2: /home/apache/pfortin.org -> /var/www/html/pfortin.org > > so... "somepath" == /home/apache/pfortin.org/Family which is really: > /home/apache/pfortin.org/Family > --> /var/www/html/pfortin.org/Family > --> /home/httpd/html/pfortin.org/Family > like this: > # ll /var/www > lrwxrwxrwx 1 root root 11 Oct 1 2001 \ > /var/www -> /home/httpd/ > # ll -d /var/www/html > drwxr-xr-x 25 apache nogroup 4096 Apr 22 12:00 \ > /var/www/html/ > # ll /home/apache/pfortin.org > lrwxrwxrwx 1 apache apache 29 Dec 27 22:50 \ > /home/apache/pfortin.org -> /var/www/html/new.pfortin.org/ > # ll -d /home/httpd/html/pfortin.org > drwxr-xr-x 34 apache apache 4096 Apr 22 12:04 \ > /home/httpd/html/pfortin.org/ > > There are many directories in ...pfortin.org; but "Family" is the only one > with this problem. > > 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 > > Gory details: > > $ stat -l /home/apache/pfortin.org/Family # see NOTE below > File: "/home/apache/pfortin.org/Family" > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 307h/775d Inode: 358385 Links: 12 > Access: (0644/drw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache) > Access: Wed Apr 24 15:06:51 2002 > Modify: Sat Apr 13 23:48:28 2002 > Change: Tue Apr 16 23:53:18 2002 > > $ stat -l /var/www/html/pfortin.org/Family > File: "/var/www/html/pfortin.org/Family" > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 307h/775d Inode: 82999 Links: 12 > Access: (0755/drwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache) > Access: Wed Apr 24 15:22:53 2002 > Modify: Sat Apr 13 23:48:28 2002 > Change: Sat Apr 20 13:11:08 2002 > > $ stat -l /home/httpd/html/pfortin.org/Family > File: "/home/httpd/html/pfortin.org/Family" > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 307h/775d Inode: 82999 Links: 12 > Access: (0755/drwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache) > Access: Wed Apr 24 15:22:53 2002 > Modify: Sat Apr 13 23:48:28 2002 > Change: Sat Apr 20 13:11:08 2002 > > Trying a directory inside the above path: > > $ stat -l /home/apache/pfortin.org/Family/1 # see NOTE below > /home/apache/pfortin.org/Family/1: Permission denied > > $ stat -l /var/www/html/pfortin.org/Family/1 > File: "/var/www/html/pfortin.org/Family/1" > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 307h/775d Inode: 83068 Links: 3 > Access: (0755/drwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache) > Access: Wed Apr 24 04:04:10 2002 > Modify: Sat Apr 13 22:07:09 2002 > Change: Sat Apr 13 23:27:58 2002 > > $ stat -l /home/httpd/html/pfortin.org/Family/1 > File: "/home/httpd/html/pfortin.org/Family/1" > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 307h/775d Inode: 83068 Links: 3 > Access: (0755/drwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache) > Access: Wed Apr 24 04:04:10 2002 > Modify: Sat Apr 13 22:07:09 2002 > Change: Sat Apr 13 23:27:58 2002 > > NOTE: This symlink has perms 0644; but that is allowed by the real > NOTE: 0755... > > Anyone know of a utility to look at the directory contents on disk? > > Any chance some unused bits got set on disk and the kernel code does not > mask them all? > > I checked the dir attributes and none are set... > > This survives a reboot, so I suspect something on disk. > > > kernel-2.4.18.5mdk-1-1mdk > > ReiserFS on / and /home > > 2.4.8-26mdkenterprise > ext2 everywhere > > > Please let me know what other information I can send to help diagnose > > this. > > Ditto... > > > -- > > > > Steve Fox > > IBM Linux Technology Center > > http://www.ibm.com/linux/ltc > > http://k-lug.org -- Gary --changing the code of the Virtual Human Brain FS Driver... The permission problem was rectified. It was caused by a race. Mounting /dev/brain0 is still causing problems, though... Here's the error: #mounting local filesystems........................................[ OK ] #Virtual Human Brain Driver v0.0.5 (EXPERIMENTAL) R/W fs module #Virtual Nerve Node Driver v0.4.1 (EXPERIMENTAL) R/W FS module #Writing Sync state to Journalled VHBFS............................[ FAILED ] Kernel Sys Oops...... Flushing registers...... Back-trace follows...... ============================================================================= Founder GVLUG. Chief Systems Architect, S4, Inc. - OS Department. Project Lead for the Sentinel Linux OS Project (KOMODO) Chairman and Project Lead of the E-media Committee of AltReal. PHONE : 895-8512 EMAIL : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ============================================================================= Sent from seele.gvsu.edu 1:51am up 17:47, 1 user, load average: 1.08, 1.15, 1.62
