Le 25/03/13 17:30, Marcel Telka a écrit :
On Mon, Mar 25, 2013 at 02:47:56PM +0100, Richard PALO wrote:
Le 25/03/13 14:26, Marcel Telka a écrit :
I reproduced this:

marcel@t2:/mnt/b/c$ nfsstat -m
/mnt from t1:/export/test
  Flags:         
vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,acl,rsize=1048576,wsize=1048576,retrans=5,timeo=600
  Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

/mnt/b from t1:/export/test/b
  Flags:         
vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,acl,mirrormount,rsize=1048576,wsize=1048576,retrans=5,timeo=600
  Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

/mnt/b/c from t1:/export/test/b/c
  Flags:         
vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,acl,mirrormount,rsize=1048576,wsize=1048576,retrans=5,timeo=600
  Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

marcel@t2:/mnt/b/c$ ls -la ..
total 5
drwxr-x--- 3 marcel staff 4 2013-03-21 01:48 .
drwxr-xr-x 4 root   root  4 2013-03-21 01:39 ..
drwxr-xr-x 2 root   root  3 2013-03-21 01:48 c
-rw-r--r-- 1 root   root  0 2013-03-21 01:43 x
marcel@t2:/mnt/b/c$ /usr/bin/pwd
/mnt/b/c
marcel@t2:/mnt/b/c$ sudo /usr/bin/pwd
pwd: cannot determine current directory!
marcel@t2:/mnt/b/c$ pfexec /usr/bin/pwd
pwd: cannot determine current directory!
marcel@t2:/mnt/b/c$


Is this what you meant?



more or less, except that in my case,
it was the second filesystem that had x-only for ".."
richard@x3200:~$ /usr/bin/ls -ladV src/. src/..
drwxrwxrwx  45 richard  staff         68 mars 24 10:45 src/.
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow
drwxr-x--x  88 richard  staff        314 mars 25 08:25 src/..
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:--x---a-R-c--s:-------:allow
richard@x3200:~$ zfs get sharenfs dpool/export/home/richard/src
NAME                           PROPERTY  VALUE                                  
         SOURCE
dpool/export/home/richard/src  sharenfs  
nosuid,[email protected]/24,[email protected]/24  inherited from dpool/export/home

Ah, I forgot in my setup to set root=blabla. Once I did so, pwd started to work
with pfexec and sudo. So, I'm unable to reproduce it.

Please try to prepare exact steps what needs to be done on cleanly installed
machines to get your issue reproduced.

Thanks.


As I indicated earlier, adding root= (as Jim seemed to indicate) was the solution, not the problem.
Thus, my problem was why execute *and* read is needed for getcwd...


I find this link with a rationale:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html

"If a program is operating in a directory where some (grand)parent directory does not permit reading, getcwd() may fail, as in most implementations it must read the directory to determine the name of the file. This can occur if search, but not read, permission is granted in an intermediate directory, or if the program is placed in that directory by some more privileged process (for example, login). Including the [EACCES] error condition makes the reporting of the error consistent and warns the application developer that getcwd() can fail for reasons beyond the control of the application developer or user.

Some implementations can avoid this occurrence (for example, by implementing getcwd() using pwd, where pwd is a set-user-root process), thus the error was made optional. Since this volume of POSIX.1-2008 permits the addition of other errors, this would be a common addition and yet one that applications could not be expected to deal with without this addition."





-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com

Reply via email to