In Solaris, doing

truss -t access,stat bash -c 'test -w /'
I get
stat64("/", 0xFFBFDE98) = 0

while with

truss -t access,stat ksh -c 'test -w /'
I get
access("/", W_OK) Err#13 EACCES [ALL]

IMHO ksh does the right thing and bash is wrong.
If you have a NetApp filer where permissions/owner are controlled from Windoze,
all files and directories appear in Unix
rwxrwxrwx root
so bash test will return always true,
while ksh test will return what the NetApp filer sais.

Could a bash expert please comment on this?

--
Michael Tosch [at] hp : com

You might want to try gnu.bash.bug, but it's possible that although bash
is using stat64 instead of access, it could be that bash has
reimplemented the additional part of access() in userspace.

Actually, if a file has mode 777 but you still can't write to it, and the
filesystem isn't readonly, and the directories leading up to it are
traversable... that would kind of make me wonder about the filesystem.
It seems like either filesystem corruption or quite a distortion of the
meaning of the permissions bits. Given this kind of scenario, I'm not
sure bash would be the only thing to get perplexed.

On Tue, 29 Jan 2008 20:59:25 +0100, Michael Tosch wrote:

> In Solaris, doing
>
> truss -t access,stat bash -c 'test -w /' I get
> stat64("/", 0xFFBFDE98) = 0
>
> while with
>
> truss -t access,stat ksh -c 'test -w /' I get
> access("/", W_OK) Err#13 EACCES [ALL]
>
> IMHO ksh does the right thing and bash is wrong. If you have a NetApp
> filer where permissions/owner are controlled from Windoze, all files and
> directories appear in Unix rwxrwxrwx root
> so bash test will return always true, while ksh test will return what
> the NetApp filer sais.
>
> Could a bash expert please comment on this?

On Tue, 29 Jan 2008 20:59:25 +0100, Michael Tosch wrote:
>
> In Solaris, doing
>
> truss -t access,stat bash -c 'test -w /'
> I get
> stat64("/", 0xFFBFDE98) = 0
>
> while with
>
> truss -t access,stat ksh -c 'test -w /'
> I get
> access("/", W_OK) Err#13 EACCES [ALL]
[...]

I has already been discussed but I don't remember the details.
All I can say is that it is intentional. You may want to try
google.

--
Stephane

In article <fno0it$o95$1 [at] deacx010.eed.ericsson.se>,
Michael Tosch <eedmit [at] NO.eed.SPAM.ericsson.PLS.se> wrote:

> In Solaris, doing
>
> truss -t access,stat bash -c 'test -w /'
> I get
> stat64("/", 0xFFBFDE98) = 0
>
> while with
>
> truss -t access,stat ksh -c 'test -w /'
> I get
> access("/", W_OK) Err#13 EACCES [ALL]
>
> IMHO ksh does the right thing and bash is wrong.
> If you have a NetApp filer where permissions/owner are controlled from
> Windoze,
> all files and directories appear in Unix
> rwxrwxrwx root
> so bash test will return always true,
> while ksh test will return what the NetApp filer sais.
>
> Could a bash expert please comment on this?

If the file server is lying about the permissions, that's not something
a Unix application should have to work around.

Also, if the shell can ever run setuid, using access() would be wrong,
as it tests the permissions of the real user, not the effective user.

--
Barry Margolin, barmar [at] alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***