![]() |
|
|
|
|
|||||||
| Forums | Portal | Register | Forum Rules | FAQ | Contribute | Members List | Arcade | Search | Today's Posts | Mark Forums Read |
| AIX AIX is IBM's industry-leading UNIX operating system that meets the demands of applications that businesses rely upon in today's marketplace. |
|
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Urgent: ACCESS PROBLEM | skyineyes | Shell Programming and Scripting | 3 | 07-11-2007 05:57 AM |
| HPUX : identify NFS mountpoint | jim mcnamara | UNIX for Advanced & Expert Users | 5 | 11-16-2005 02:46 PM |
| UNIX, remote access problem | pdepa | UNIX for Advanced & Expert Users | 1 | 12-03-2003 12:54 PM |
| Updating and Creating Web pages wiht Unix | gsensebe | UNIX for Dummies Questions & Answers | 1 | 01-09-2002 11:08 AM |
| ftp access problem | bache_gowda | UNIX for Dummies Questions & Answers | 1 | 09-17-2001 10:06 AM |
|
|
Submit Tools | LinkBack | Thread Tools | Search this Thread | Display Modes |
|
#1
|
|||
|
|||
|
Access problem wiht mountpoint, 5.1 ML6
I have experienced a strange effect on one of our machines and would like to ask, if somebody else can verify this. Machine is a LPAR in a 690, OS is 5.1, ML 6.
I create a new group and a new user, who has this group set as his primary group he will be in no other group. Then, as root, create a directory as a future mountpoint, but remove all rights for others to this directory (like in "UMASK 27" prior to creating it). Then i create a filesystem (jfs2, but the type won't matter) and mount it into this directory. Only now i give the user and his group ownership for the mounted fs. Now everything looks fine, and the user has every right on the fs. However, wenn i switch to the user and make the new fs my PWD, a simple "find /usr -print" will terminate before even one file is found with some strange errormessage it can't stat a file. The cure is, to log on as root again, umount the fs, change the r- and x-bits of the mountpoint and remount the fs. Seemingly this changes nothing, but the rather strange effect will be gone. Has anybody experienced something similar to that? (And, yes, of course I've opened a software call.) Here is a terminal log of what I've done: Code:
# The following is just preliminary to set up the test conditions,
# neither does the size, location, mountpoint, etc. of the created
# filesystem matter, nor does the usage of JFS instead of JFS2 or
# vice versa.
root@fubar:/ # cd /tmp
root@fubar:/tmp # mkdir pmrtest
root@fubar:/tmp # ls -ld pmrtest
drwxr-x--- 2 root system 256 May 13 16:14 pmrtest
root@fubar:/tmp # mklv -y fubarlv rootvg 1
fubarlv
root@fubar:/tmp # crfs -v jfs \
-d fubarlv \
-m /tmp/pmrtest \
-A no \
-p rw \
-t no \
-a frag=4096 \
-a nbpi=4096 \
-a ag=8
Based on the parameters chosen, the new /tmp/pmrtest JFS file system
is limited to a maximum size of 134217728 (512 byte blocks)
New File System size is 65536
root@fubar:/tmp # mount /tmp/pmrtest
root@fubar:/tmp # ls -ld /tmp/pmrtest
drwxr-sr-x 3 sys sys 512 May 13 16:24 /tmp/pmrtest
root@fubar:/tmp # mkgroup -A id=1000000 pmrtest
root@fubar:/tmp # mkuser id=1000000 \
pgrp=staff \
groups='staff, pmrtest' \
sugroups=ALL pmrtest
root@fubar:/tmp # lsuser pmrtest
pmrtest id=1000000 pgrp=staff groups=staff,pmrtest home=/home/pmrtest
shell=/usr/bin/ksh login=false su=false rlogin=false daemon=true admin=false
sugroups=ALL tpath=on ttys=ALL expires=0 auth1=SYSTEM auth2=NONE
umask=77 registry=files SYSTEM=files loginretries=3 pwdwarntime=14
account_locked=false minage=0 maxage=13 maxexpired=0 minalpha=1
minother=1 mindiff=3 maxrepeats=2 minlen=7 histexpire=0 histsize=9
fsize=2097151 cpu=-1 data=131072 stack=32768 core=1024 rss=32768
nofiles=2000 core_hard=1024 roles=
root@fubar:/tmp # chown pmrtest:pmrtest /tmp/pmrtest
root@fubar:/tmp # ls -ld pmrtest
drwxr-sr-x 3 pmrtest pmrtest 512 May 13 16:24 pmrtest
# ok, end of preliminary tasks. Now the real test case:
root@fubar:/tmp # su - pmrtest
pmrtest@fubar:/home/pmrtest $ find /usr -print
<...some long list SNIPped...>
pmrtest@fubar:/home/pmrtest $ cd /tmp/pmrtest
pmrtest@fubar:/tmp/pmrtest $ find
pwd: The file access permissions do not allow the specified action.
pmrtest@fubar:/tmp/pmrtest $ cd -
/home/pmrtest
pmrtest@fubar:/home/pmrtest $ find /usr -print
<...the same long list SNIPped again...>
# No, this has nothing to do with the find command itself,
# /usr/bin/find just is used as an example here. As you can see
# in the lines before and after /usr/bin/find *can* be used,
# depending on the PWD of your session and *this* is the real
# problem. Now for the cure, which shows how weird that all
# really is:
pmrtest@fubar:/home/pmrtest $ exit
root@fubar:/tmp # umount /tmp/pmrtest
root@fubar:/tmp # ls -ld /tmp/pmrtest
drwxr-x--- 2 root system 256 May 13 16:14 pmrtest
root@fubar:/tmp # chmod o+rx pmrtest
root@fubar:/tmp # ls -ld pmrtest
drwxr-xr-x 2 root system 256 May 13 16:14 pmrtest
root@fubar:/tmp # mount /tmp/pmrtest
root@fubar:/tmp # ls -ld /tmp/pmrtest
drwxr-sr-x 3 pmrtest pmrtest 512 May 13 16:24 /tmp/pmrtest
# notice, that *after* the mount the filemode of the directory appear
# to be exactly the same as before, but with a *slight* difference:
root@fubar:/tmp # su - pmrtest
pmrtest@fubar:/home/pmrtest $ find /usr -print
<...the same long list SNIPped again...>
pmrtest@fubar:/tmp/pmrtest $ find /usr -print
<...the long awaited list appears...>
|
| Forum Sponsor | ||
|
|
|
#2
|
|||
|
|||
|
I have seen this issue also, basically the permissions of the mount point are affecting the behavior of the filesystem at some level. I think it is probably a bug.
Jim Hirschauer Last edited by RTM; 07-26-2005 at 11:04 AM. |
|||
| Google The UNIX and Linux Forums |