HELP! "pwd" != "/usr/bin/pwd" (AIX)
Jaroslaw Banachowicz
We have experienced strange (weird?!) problem on one of our
environments:
klio:/lido_apps/users/lido$ pwd
/lido_apps/users/lido
klio:/lido_apps/users/lido$ /usr/bin/pwd
pwd: Permission denied
klio:/lido_apps/users/lido$ cd ..
klio:/lido_apps/users$ /usr/bin/pwd
pwd: Permission denied
klio:/lido_apps/users$ cd ..
klio:/lido_apps$ /usr/bin/pwd
/lido_apps
As you can see we are not able to execute command "/usr/bin/pwd" (as
user lido with home directory "/lido_apps/users/lido"), but everything
is fine with just "pwd".
At the first look it seems to be dependable on the depth of
subdirectories - but it is not (as the same user):
klio:/usr/bin$ /usr/bin/pwd
/usr/bin
The AIX version is 4.3.3 ML 6.
Can anybody help us???
Regards,
--
Jaroslaw Banachowicz
Lido GmbH (FRA OD/T-SMG)
Lufthansa Aeronautical Services jaroslaw.b...@lido.net
Jaroslaw Banachowicz
bos.net.nfs.adt 4.3.3.25 C Network File System
Development
bos.net.nfs.cachefs 4.3.3.25 C CacheFS File System
bos.net.nfs.client 4.3.3.25 C Network File System Client
bos.net.nfs.server 4.3.3.10 C Network File System Server
Anthony W. Youngman
says that Korn includes it as a builtin. So if you're running the Korn
shell, "pwd" executes the shell internal, while /usr/bin/pwd tries to
execute the external program.
So yes, they won't be the same ...
Jaroslaw Banachowicz
> So yes, they won't be the same ...
Yes, you are right:
klio:/lido_apps/users/lido$ type pwd
pwd is a shell builtin.
klio:/lido_apps/users/lido$ which pwd
/usr/bin/pwd
We know that already. But how can this be of any importance?
Anthony W. Youngman
wondering why it works sometimes and not others.
pwd is part of the shell. If the user can log in then they can use
anything that is part of the shell. pwd will ALWAYS work, and for ANY
user BECAUSE it is a shell builtin.
/usr/bin/pwd is a program. It relies on access permissions and any other
stuff. All I can presume is that user lido does not have x access to the
file /usr/bin/pwd. Therefore he can't run it. Because pwd has ABSOLUTELY
NO RELATIONSHIP WHATSOEVER to /usr/bin/pwd (apart from the fact they
both APPEAR to have the same result), then the fact that he can run pwd
(because it is part of the shell it will always work) has no bearing on
whether he can run /usr/bin/pwd.
By your logic, if "pwd" works, then "cat /etc/passwd" should also work
...
-----Original Message-----
From: Jaroslaw Banachowicz [mailto:jaroslaw.b...@lido.net]
Posted At: 31 January 2001 11:56
Posted To: admin
Conversation: HELP! "pwd" != "/usr/bin/pwd" (AIX)
Jaroslaw Banachowicz
>
> It's important because you are comparing apples with oranges and then
> wondering why it works sometimes and not others.
> By your logic, if "pwd" works, then "cat /etc/passwd" should also work
Well, you don't have to flame me. I know the difference of course, but
once again: how this can be a reason for this problem? Please note, that
/usr/bin/pwd doesn't work only sometimes:
klio:/lido_apps/users$ /usr/bin/pwd
pwd: Permission denied
klio:/lido_apps/users$ cd ..
klio:/lido_apps$ /usr/bin/pwd
/lido_apps
!!!!!!!!!!!!!
There is one more thing I've "discovered" meanwhile:
klio:/lido_data/FEPool$ lssrc -g nfs
Subsystem Group PID Status
rpc.statd nfs 8008 active
nfsd nfs 14042 active
rpc.mountd nfs 7208 active
rpc.lockd nfs 12746 active
biod nfs inoperative !!!!!!!!!!!!!!
Can this be a reason?
Anthony W. Youngman
speak English as your native language (you're from Poland or the Former
Soviet Union?)
As I understood your original post, pwd worked, but (for a particular
user) /usr/bin/pwd didn't. That screams "file permissions" at me, and
the fact that pwd on its own works is a red herring to the main problem.
Now you've pointed out that /usr/bin/pwd works "randomly", then it's
strange.
Try doing an ls where /usr/bin/pwd doesn't work. Maybe it needs r
permissions on the directory (you don't need r to cd, only x).
Especially with eg /lido_apps/users, r rights may have been suppressed
as a security measure. I'm getting out of my depth now, but security
issues can cause really weird headaches, and I guess I guess it's
something to do with the current directory. It's certainly not
/usr/bin/pwd if that works elsewhere (and it's not the pwd builtin -
that will simply have cached the path from the cd command, so it won't
need to read the directory name and won't fall foul of permissions).
(I've know someone take away x rights somewhere in the path to the home
directory on a different OS, and boy did that cause some weird errors
:-)
-----Original Message-----
From: Jaroslaw Banachowicz [mailto:jaroslaw.b...@lido.net]
Posted At: 31 January 2001 12:40
Posted To: admin
Conversation: HELP! "pwd" != "/usr/bin/pwd" (AIX)
Subject: Re: HELP! "pwd" != "/usr/bin/pwd" (AIX)
Jaroslaw Banachowicz
>
> Sorry if I came over a little sharp. I do appreciate you appear not to
> speak English as your native language
Thanks :-)
> (you're from Poland or the Former
> Soviet Union?)
Poland. Why?
> As I understood your original post, pwd worked, but (for a particular
> user) /usr/bin/pwd didn't. That screams "file permissions" at me, and
> the fact that pwd on its own works is a red herring to the main problem.
> Now you've pointed out that /usr/bin/pwd works "randomly", then it's
> strange.
Tell me more... :-(
> Try doing an ls where /usr/bin/pwd doesn't work. Maybe it needs r
> permissions on the directory (you don't need r to cd, only x).
Nop. We have checked all the permissions as a first thing. ls works fine
everywhere :-(
I checked the versions of nfs packets as well:
klio:/lido_data/AIRP_RWY_WX$ lslpp -L|grep bos.net.nfs
bos.net.nfs.adt 4.3.3.25 C Network File System
Development
bos.net.nfs.cachefs 4.3.3.25 C CacheFS File System
bos.net.nfs.client 4.3.3.25 C Network File System Client
bos.net.nfs.server 4.3.3.10 C Network File System Server
So, afaik, they are up to date.
We started biod resource as well, but it didn't help too.
Since we have a machine without bos.net.nfs.server running without any
problems, I suggested to deinstall this packet from klio as well. I'm
waiting for results now.
Jefferson Ogata
>
> Hi.
>
> We have experienced strange (weird?!) problem on one of our
> environments:
>
> klio:/lido_apps/users/lido$ pwd
> /lido_apps/users/lido
> klio:/lido_apps/users/lido$ /usr/bin/pwd
> pwd: Permission denied
> klio:/lido_apps/users/lido$ cd ..
> klio:/lido_apps/users$ /usr/bin/pwd
> pwd: Permission denied
> klio:/lido_apps/users$ cd ..
> klio:/lido_apps$ /usr/bin/pwd
> /lido_apps
>
> As you can see we are not able to execute command "/usr/bin/pwd" (as
> user lido with home directory "/lido_apps/users/lido"), but everything
> is fine with just "pwd".
> At the first look it seems to be dependable on the depth of
> subdirectories - but it is not (as the same user):
> klio:/usr/bin$ /usr/bin/pwd
> /usr/bin
>
> The AIX version is 4.3.3 ML 6.
Is /lido_apps/users a separate mount? If so, umount it and check the
permissions on the underlying directory it was mounted on. Make sure it is
rwxr-xr-x.
If that doesn't help, do an ls -ld . on each of the directories you are showing
us in the above example and post that.
Does it matter whether you are superuser?
--
Jefferson Ogata : Internetworker, Antibozo
<og...@antibozo-u-spam-u-die.net> http://www.antibozo.net/ogata/
whois: jo...@whois.networksolutions.com
Jefferson Ogata
>
> "Anthony W. Youngman" wrote:
>
> > So yes, they won't be the same ...
>
> Yes, you are right:
>
> klio:/lido_apps/users/lido$ type pwd
> pwd is a shell builtin.
> klio:/lido_apps/users/lido$ which pwd
> /usr/bin/pwd
>
> We know that already. But how can this be of any importance?
It's of importance because the shell's pwd tells you what the shell believes is
its cwd based on the cd path you've taken on the command line. /usr/bin/pwd
doesn't know anything about that; it does a recursive ascent to the root and
reports the reverse path to tell you where you are. The latter requires
filesystem permissions that the former doesn't -- the shell doesn't even need
to look at the filesystem to tell you where it believes you are.
Nate Eldredge
> "Anthony W. Youngman" wrote:
> >
> > It's important because you are comparing apples with oranges and then
> > wondering why it works sometimes and not others.
> CUT
> > By your logic, if "pwd" works, then "cat /etc/passwd" should also work
>
> Well, you don't have to flame me. I know the difference of course, but
> once again: how this can be a reason for this problem? Please note, that
> /usr/bin/pwd doesn't work only sometimes:
>
> klio:/lido_apps/users$ /usr/bin/pwd
> pwd: Permission denied
You might try `truss' or your local equivalent to determine exactly
what is failing here. Superficially you might think that permission
is denied to execute /usr/bin/pwd (i.e. `execve' is failing). But
what I suspect is actually the case is that permission is denied to
look at the current directory (either `stat' or `getcwd' is failing).
I'll bet a lot that you don't have read or execute permissions on
/lido_apps/users, which would explain this, and the error message from
`pwd' is just somewhat misleading.
> klio:/lido_apps/users$ cd ..
> klio:/lido_apps$ /usr/bin/pwd
> /lido_apps
>
> !!!!!!!!!!!!!
--
Nate Eldredge
neld...@hmc.edu
Bill Pemberton
Jaroslaw Banachowicz <jaroslaw.b...@lido.net> wrote:
>"Anthony W. Youngman" wrote:
>>
>> It's important because you are comparing apples with oranges and then
>> wondering why it works sometimes and not others.
>CUT
>> By your logic, if "pwd" works, then "cat /etc/passwd" should also work
>
>Well, you don't have to flame me. I know the difference of course, but
>once again: how this can be a reason for this problem? Please note, that
>/usr/bin/pwd doesn't work only sometimes:
>
>klio:/lido_apps/users$ /usr/bin/pwd
>pwd: Permission denied
>klio:/lido_apps/users$ cd ..
>klio:/lido_apps$ /usr/bin/pwd
>/lido_apps
>
>!!!!!!!!!!!!!
>
And now about about ls -ld /lido_apps/users .
I bet the permissions are such that you can stat it.
Also, since you're running down the path of NFS, I'll assume this is
in an NFS mounted filesystem. By any chance are you doing this as
root on filesystem that isn't exported with root privs? (Remember, in
this case you are user nobody on the server side).
--
Bill
Bill Pemberton
>>
>> It's important because you are comparing apples with oranges and then
>> wondering why it works sometimes and not others.
>CUT
>> By your logic, if "pwd" works, then "cat /etc/passwd" should also work
>
>Well, you don't have to flame me. I know the difference of course, but
>once again: how this can be a reason for this problem? Please note, that
>/usr/bin/pwd doesn't work only sometimes:
>
>klio:/lido_apps/users$ /usr/bin/pwd
>pwd: Permission denied
>klio:/lido_apps/users$ cd ..
>klio:/lido_apps$ /usr/bin/pwd
>/lido_apps
>
>!!!!!!!!!!!!!
>
And now about about ls -ld /lido_apps/users .
I bet the permissions are such that you can't stat it.
Jaroslaw Banachowicz
> And now about about ls -ld /lido_apps/users .
Here you are:
klio:/lido_apps/users/lido$ ls -ld /lido_apps/users
drwxr-xr-x 44 bin bin 1024 Jan 16 10:44 /lido_apps/users
klio:/lido_apps/users/lido$ ls -ld /lido_apps
drwxr-sr-x 6 lido lido 512 Jan 15 15:09 /lido_apps
That was the first thing I checked...
> I bet the permissions are such that you can't stat it.
How much do you own me? ;-)
Bill Pemberton
Jaroslaw Banachowicz <jaroslaw.b...@lido.net> wrote:
>Bill Pemberton wrote:
>
>> And now about about ls -ld /lido_apps/users .
>
>Here you are:
>
>klio:/lido_apps/users/lido$ ls -ld /lido_apps/users
>drwxr-xr-x 44 bin bin 1024 Jan 16 10:44 /lido_apps/users
>klio:/lido_apps/users/lido$ ls -ld /lido_apps
>drwxr-sr-x 6 lido lido 512 Jan 15 15:09 /lido_apps
>
>That was the first thing I checked...
>
>> I bet the permissions are such that you can't stat it.
>
>How much do you own me? ;-)
>
Nothing until you read the rest of my message.....
For grins, now cd into /lido_apps/users and try ls -ld .
--
Bill
Jefferson Ogata
> Bill Pemberton wrote:
>
> > And now about about ls -ld /lido_apps/users .
>
> Here you are:
>
> klio:/lido_apps/users/lido$ ls -ld /lido_apps/users
> drwxr-xr-x 44 bin bin 1024 Jan 16 10:44 /lido_apps/users
> klio:/lido_apps/users/lido$ ls -ld /lido_apps
> drwxr-sr-x 6 lido lido 512 Jan 15 15:09 /lido_apps
>
> That was the first thing I checked...
>
> > I bet the permissions are such that you can't stat it.
>
> How much do you own me? ;-)
You didn't respond to my previous post. If you want help, you need to provide
more information.
Is /lido_apps/users a separate filesystem or not? If so, did you check the
permissions of the underlying mount point directory?
Post the results of "ls -lid . .." in each of the directories:
/lido_apps
/lido_apps/users
/lido_apps/users/lido
Run your system call trace program on /usr/bin/pwd and post the results of
that.
Jaroslaw Banachowicz
> For grins, now cd into /lido_apps/users and try ls -ld .
It works fine.
--
Jaroslaw Banachowicz
Lido GmbH (FRA OD/T-SMG) tel. +49 (0) 69 696-9 55 19
Lufthansa Aeronautical Services jaroslaw.b...@lido.net
Jaroslaw Banachowicz
Here you are with the example:
klio:/lido_data$ ls -ld
drwxrwsr-x 32 lidodata lido 1536 Jan 31 23:45 .
klio:/lido_data$ /usr/bin/pwd
/lido_data
klio:/lido_data$ cd FEPool
klio:/lido_data/FEPool$ ls -ld
drwxrwsr-x 7 lido lido 512 Jan 12 10:18 .
klio:/lido_data/FEPool$ /usr/bin/pwd
pwd: Permission denied
Done as user 'lido'.
What now?
--
Jaroslaw Banachowicz
Jaroslaw Banachowicz
> You didn't respond to my previous post. If you want help, you need to provide
> more information.
Right.
> Is /lido_apps/users a separate filesystem or not? If so, did you check the
> permissions of the underlying mount point directory?
Yes, it is. I'm waiting for the same answer from their superuser now.
> Post the results of "ls -lid . .." in each of the directories:
>
> /lido_apps
> /lido_apps/users
> /lido_apps/users/lido
OK, I discovered this:
klio:/lido_apps/users$ ls -ld
drwxr-xr-x 44 bin bin 1024 Jan 16 10:44 .
But we _do_ have such a settings on another system and it works fine.
But how about this:
klio:/lido_data$ ls -ld
drwxrwsr-x 32 lidodata lido 1536 Jan 31 23:45 .
klio:/lido_data$ /usr/bin/pwd
/lido_data
klio:/lido_data$ cd FEPool
klio:/lido_data/FEPool$ ls -ld
drwxrwsr-x 7 lido lido 512 Jan 12 10:18 .
klio:/lido_data/FEPool$ /usr/bin/pwd
pwd: Permission denied
> Run your system call trace program on /usr/bin/pwd and post the results of
> that.
I can't. I don't have root access.
But I'm going to send this request to their admin.
--
Jaroslaw Banachowicz
Jefferson Ogata
> Jefferson Ogata wrote:
>
> > You didn't respond to my previous post. If you want help, you need to provide
> > more information.
>
> Right.
>
> > Is /lido_apps/users a separate filesystem or not? If so, did you check the
> > permissions of the underlying mount point directory?
>
> Yes, it is. I'm waiting for the same answer from their superuser now.
I'm referring to the directory /lido_apps/users on klio, with the
/lido_apps/users filesystem unmounted. I.e. the local directory underlying the
mount of /lido_apps/users. You need superuser privileges on klio to do this,
since you have to umount /lido_apps/users. You don't need an account on any
other machine.
> > Post the results of "ls -lid . .." in each of the directories:
> >
> > /lido_apps
> > /lido_apps/users
> > /lido_apps/users/lido
>
> OK, I discovered this:
>
> klio:/lido_apps/users$ ls -ld
> drwxr-xr-x 44 bin bin 1024 Jan 16 10:44 .
You didn't do what I asked. I asked for "ls -lid . .." in each of the
directories:
/lido_apps
/lido_apps/users
/lido_apps/users/lido
What you did was "ls -ld" on one of those paths. You're wasting my time.
> But we _do_ have such a settings on another system and it works fine.
>
> But how about this:
>
> klio:/lido_data$ ls -ld
> drwxrwsr-x 32 lidodata lido 1536 Jan 31 23:45 .
> klio:/lido_data$ /usr/bin/pwd
> /lido_data
> klio:/lido_data$ cd FEPool
> klio:/lido_data/FEPool$ ls -ld
> drwxrwsr-x 7 lido lido 512 Jan 12 10:18 .
> klio:/lido_data/FEPool$ /usr/bin/pwd
> pwd: Permission denied
>
> > Run your system call trace program on /usr/bin/pwd and post the results of
> > that.
>
> I can't. I don't have root access.
> But I'm going to send this request to their admin.
You don't need root access to run your system call trace program. I don't use
AIX much so I don't know what it's called there, but on other *nix systems it
is variously called par, strace, trace, or truss. Run /usr/bin/pwd under that
program in one of the directories that is giving you trouble and post the
results.
Bill Pemberton
Jaroslaw Banachowicz <ba...@nets.pl> wrote:
>Bill Pemberton wrote:
>
>Here you are with the example:
>
>klio:/lido_data$ ls -ld
>drwxrwsr-x 32 lidodata lido 1536 Jan 31 23:45 .
>klio:/lido_data$ /usr/bin/pwd
>/lido_data
>klio:/lido_data$ cd FEPool
>klio:/lido_data/FEPool$ ls -ld
>drwxrwsr-x 7 lido lido 512 Jan 12 10:18 .
>klio:/lido_data/FEPool$ /usr/bin/pwd
>pwd: Permission denied
>
>Done as user 'lido'.
>
>What now?
>
I suspect it's the permissions on underlying mount point (I'm still
guessing here, since we're still not sure you've got something else
mounted in there).
For example, let's say you have a directory called /mnt/blah that
looks like this:
# ls -ld /mnt/blah
d--------- 2 root system 512 Feb 1 15:13 /mnt/blah
Obviously, only root can deal with this directory.
(ok, this is overkill, but it'll show the problem)
Now, you NFS mount something onto /mnt/blah and it has permissions a
normal user can get to, can cd to, and use fine. Here's my
examples permissions after the mount:
# ls -ld /mnt/blah
drwxr-sr-x 30 root sys 1024 Dec 7 16:01 /mnt/blah
However, if I now cd to the directory and do /bin/pwd, I'll get the
error you're getting.
unmount whatever is there, check the permissions on the mount points.
--
Bill
Jaroslaw Banachowicz
> I suspect it's the permissions on underlying mount point (I'm still
> guessing here, since we're still not sure you've got something else
> mounted in there).
OK, maybe this is the reason. It is mounted, so I requested their root
to unmount it and check the permissions. I'm still waiting for him to do
that.
Meanwhile I'm going to create a situation like described by you on
another machine and see if the error occurs.
Jaroslaw Banachowicz
> unmount whatever is there, check the permissions on the mount points.
OK, I recreated the situation described by you at the other system and
you were right.
I'm going to contact klio's superuser now and ask him to check the
permissions on mount points.
Thanks a lot for your help!
Jaroslaw Banachowicz
> You're wasting my time.
Sorry for that.
I followed Bill Pemberton's suggestion to investigate permissions on
mount points. I recreated the situation on another system and the error
occured.
I'm going to contact klio's superuser now and ask him to check the
permissions on mount points.
Thanks a lot for your help!
--
Jefferson Ogata
> Jefferson Ogata wrote:
>
> > You're wasting my time.
>
> Sorry for that.
> I followed Bill Pemberton's suggestion to investigate permissions on
> mount points. I recreated the situation on another system and the error
> occured.
> I'm going to contact klio's superuser now and ask him to check the
> permissions on mount points.
> Thanks a lot for your help!
If you go back through the thread, you'll see I gave you the same advice about
three times, including back on Wednesday at 1733 UTC when I wrote:
> Is /lido_apps/users a separate mount? If so, umount it and check the
> permissions on the underlying directory it was mounted on. Make sure it is
> rwxr-xr-x.
Sheesh.