Very Computer

        "G. Low" <donotreplayATnowhereDOTcom> writes:

Quote:> Hi! I was wondering about the odd behaviour of the "pwd", "df" commands
> (perhaps others I haven't run into) after I Live Upgraded my system from
> Sol9u4 to Sol9u6...
> I pkgrm'ed SUNWluu & SUNWlur that comes with Sol9u4, and pkgadd'ed the 2
> pkgs from Sol9u6...lucreated my ABE:

> lucreate -c "sol9u4" \
> -m /:/dev/dsk/c0t0d0s5:ufs \
> -m /var:/dev/dsk/c0t0d0s6:ufs \
> -m /opt:/dev/dsk/c0t0d0s7:ufs \
> -n "sol9u6"

> And then luugrade'ed it this way:

> luupgrade -u -n "sol9u6" \
> -s /net/mysparc/sol9u6

> The upgrade goes ok, and once it finishes, and I activate the "sol9u6"
> environment, once I logon, the "pwd" command fails in certain directories...

> -----
> google% pwd
> pwd: cannot determine current directory!
> google% df -k .
> df: cannot canonicalize .: Permission denied
> google%
> google% cd
> google% pwd
> /export/home/solaris
> google% df -k .
> Filesystem            kbytes    used   avail capacity  Mounted on
> /dev/dsk/c0t1d0s7    2992760 1174337 1788496    40%    /export/home
> google%

One or more of the directories leading to the one where the problem
occurs has permissions that are too restrictive; probably missing
the public execute bit.

Perhaps something you did was influenced by the umask you had in effect
at the time (although IMO it ought to be a bug for pkgadd or liveupgrade
to be affected by umask).

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Yep, it's the permissions on the underlying mount point... I would try this:

umount /export/home
chmod 755 /export/home
mount /export/home

should take care of the problem....

Now wait a minute - I thought underlying mount point permissions only
were used by certain filesystems (like to provide initial top-level
permission for tmpfs filesystems).  I'm fairly sure they're _not_ used
by ufs.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Quote:>>> > google% pwd
>>> > pwd: cannot determine current directory!
>>> > google% df -k .
>>> > df: cannot canonicalize .: Permission denied
>>> > google%
>>> > google% cd
>>> > google% pwd
>>> > /export/home/solaris
>>> > google% df -k .
>>> > Filesystem            kbytes    used   avail capacity  Mounted on
>>> > /dev/dsk/c0t1d0s7    2992760 1174337 1788496    40%    /export/home
>>> > google%
>> Yep, it's the permissions on the underlying mount point... I would try this:

>> umount /export/home
>> chmod 755 /export/home
>> mount /export/home

>> should take care of the problem....
> Now wait a minute - I thought underlying mount point permissions only
> were used by certain filesystems (like to provide initial top-level
> permission for tmpfs filesystems).  I'm fairly sure they're _not_ used
> by ufs.

'used' or 'supposed to be used'?  

I don't know if it's an actual bug or not, but the behavior of
underlying permissions on the mount point causing this kind of problem
has been in UFS for some time.

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Seems ok now:

# mkdir /test_mount
# chmod 0100 /test_mount
# ls -ld /test_mount
d--x------   2 root     other        512 Aug 25 10:56 /test_mount
# mount /dev/dsk/c3t0d0s0 /test_mount
# ls -ld /test_mount
drwxrwxrwx  41 nobody   nobody      2048 Dec  2  2003 /test_mount
# umount /test_mount
# ls -ld /test_mount
d--x------   2 root     other        512 Aug 25 10:56 /test_mount
# uname -a
SunOS mindwarp 5.9 Generic_117171-08 sun4u sparc SUNW,Sun-Blade-100

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Quote:>>>>> > google% pwd
>>>>> > pwd: cannot determine current directory!
>>>>> > google% df -k .
>>>>> > df: cannot canonicalize .: Permission denied
>>>>> > google%
>>>>> > google% cd
>>>>> > google% pwd
>>>>> > /export/home/solaris
>>>>> > google% df -k .
>>>>> > Filesystem            kbytes    used   avail capacity  Mounted on
>>>>> > /dev/dsk/c0t1d0s7    2992760 1174337 1788496    40%    /export/home
>>>>> > google%

>>>> Yep, it's the permissions on the underlying mount point... I would try this:

>>>> umount /export/home
>>>> chmod 755 /export/home
>>>> mount /export/home

>>>> should take care of the problem....

>>> Now wait a minute - I thought underlying mount point permissions only
>>> were used by certain filesystems (like to provide initial top-level
>>> permission for tmpfs filesystems).  I'm fairly sure they're _not_ used
>>> by ufs.

>> 'used' or 'supposed to be used'?  

>> I don't know if it's an actual bug or not, but the behavior of
>> underlying permissions on the mount point causing this kind of problem
>> has been in UFS for some time.
> Seems ok now:
> # mkdir /test_mount
> # chmod 0100 /test_mount
> # ls -ld /test_mount
> d--x------   2 root     other        512 Aug 25 10:56 /test_mount
> # mount /dev/dsk/c3t0d0s0 /test_mount
> # ls -ld /test_mount
> drwxrwxrwx  41 nobody   nobody      2048 Dec  2  2003 /test_mount
> # umount /test_mount
> # ls -ld /test_mount
> d--x------   2 root     other        512 Aug 25 10:56 /test_mount
> # uname -a
> SunOS mindwarp 5.9 Generic_117171-08 sun4u sparc SUNW,Sun-Blade-100

Does the '#' on your prompt imply that you're root?  Permissions issues
don't usually apply to root.

# ls -ld /mnt/ufs
d--x------   2 root     other        512 Aug 12 11:38 /mnt/ufs
# mount /dev/vx/dsk/ufsvol /mnt/ufs
# ls -ld /mnt/ufs
drwxr-xr-x   3 root     root         512 Aug 12 11:39 /mnt/ufs
# su - bob
$ csh
% pwd
/tmp
% pwd
pwd: cannot determine current directory!
% ls -ld .
drwxr-xr-x   3 root     root         512 Aug 12 11:39 .
% ls -la
./..: Permission denied
total 66
drwxr-xr-x   3 root     root         512 Aug 12 11:39 .
drwx------   2 root     root        8192 Aug 12 11:38 lost+found
-rw-r--r--   1 root     other    2071648 Aug 12 11:41 quotas

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Quote:> Does the '#' on your prompt imply that you're root?  Permissions issues
> don't usually apply to root.
> # ls -ld /mnt/ufs
> d--x------   2 root     other        512 Aug 12 11:38 /mnt/ufs
> # mount /dev/vx/dsk/ufsvol /mnt/ufs
> # ls -ld /mnt/ufs
> drwxr-xr-x   3 root     root         512 Aug 12 11:39 /mnt/ufs
> # su - bob
> $ csh
> % pwd
> /tmp
> % pwd
> pwd: cannot determine current directory!

Okay, so my cut & paste from the other window missed a line....  There
should have been a 'cd /mnt/ufs' between the pwds...

Quote:> % ls -ld .
> drwxr-xr-x   3 root     root         512 Aug 12 11:39 .
> % ls -la
> ./..: Permission denied
> total 66
> drwxr-xr-x   3 root     root         512 Aug 12 11:39 .
> drwx------   2 root     root        8192 Aug 12 11:38 lost+found
> -rw-r--r--   1 root     other    2071648 Aug 12 11:41 quotas

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

You're doing it as root, that's why it succeeded.

Unix has always behaved this way; if the directory a filesystem is
mounted on has restrictive permissions then pwd can fail.

Ok, I use ksh which hides the problem with its built-in pwd.  But I can
recreate it if I run /bin/pwd.  A truss reveals

3172/1:         open("./..", O_RDONLY|O_NDELAY|O_LARGEFILE)     Err#13 EACCES

If I had to take a guess, ./.. is being mapped to the ./.. of the
underlying mount point, but the permissions of the underlying ./. are
preventing that from being accessed.  Sounds like it would take only
a couple of lines of code (possibly repeated in one or two places) to
fix that one!

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Quote:> You're doing it as root, that's why it succeeded.

> Unix has always behaved this way; if the directory a filesystem is
> mounted on has restrictive permissions then pwd can fail.

Ok, I just recreated it, and in another post pegged it to EACCESS on
the .. of the top-level directory of the mounted filesystem, which is
apparently being mapped to the underlying mount point, and incorrectly,
the permissions on the underlying mount point are being applied to
accessing that even when it's a special case like that.

I would think that permission 0111 on the underlying mount point would be
sufficient to prevent that until (if/when) it's fixed.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

[...]

Quote:> Ok, I use ksh which hides the problem with its built-in pwd.  But I can
> recreate it if I run /bin/pwd.  A truss reveals

> 3172/1:         open("./..", O_RDONLY|O_NDELAY|O_LARGEFILE)     Err#13 EACCES

> If I had to take a guess, ./.. is being mapped to the ./.. of the
> underlying mount point, but the permissions of the underlying ./. are
> preventing that from being accessed.  Sounds like it would take only
> a couple of lines of code (possibly repeated in one or two places) to
> fix that one!

For the Solaris 8 FCS code, the relevant source file appears to be
src/uts/common/fs/lookup.c; that's about all I can say here...hopefully
one of the Sun guys (Casper, where are you???) will take the hint, file
a bug, and maybe even a fix.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

The more I look at it, the more I wonder if the problem could be fixed (or
worked around) in lookup.c.  Imagine doing a /bin/pwd somewhere below an
NFS mount on top of a subdirectory of another NFS mount (could certainly
exist on a diskless client).  Now since root doesn't (without special
arrangements which a diskless client might well have had made for it) work
over NFS, a temporary fudging of credentials when looking up ".." in the
underlying filesystem wouldn't necessarily be good enough.

If filesystems "knew" which of their vnodes had something mounted on top
of them (and what it was), they could grant  for ".." in those directories
the execute permissions of the directory mounted on top of them rather
than those of the underlying mount point.  (sorry, I don't know how to
say some of this in a non-convoluted way)  But that gets worse too,
since a server could have multiple clients mounting directories with
different permissions on top of the same mount point that they export.

Otherwise, a solution would be to allow whatever was needed for
stat() of any ".." to succeed, whether it was a redirection to the
one underlying a mount point or not.  But that has broader scope than
necessary and doesn't honor the perms of the one on top, so presumably
it has security implications; I haven't thought through how serious they
are...

So depending on whether there's an easy and good way that I'm missing,
or whether something less precise than the obvious expectation might
be ok, it might take changes to each filesystem plus to the generic
code plus perhaps even to the interface between the two; and even then,
it may be not just a lot of work, but introduce all sorts of other
unacceptable problems.  Yikes.

Still, I hope someone who can get somewhere with it (and is more
experienced with the internals than I am) would take a look at it.
IMO, the reasonable expectation is that while ".." in the root of
a mounted filesystem is redirected to the underlying "..", the permissions
of the one on top (as seen by that client system) should still apply.

I don't even want to think of where that all goes when you throw in the
enhanced lofs that's part of zone support...my head hurts, and my
coffee has worn off now.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

[Richard L. Hamilton]:

Quote:

>   For the Solaris 8 FCS code, the relevant source file appears to be
>   src/uts/common/fs/lookup.c; that's about all I can say
>   here...hopefully one of the Sun guys (Casper, where are you???)
>   will take the hint, file a bug, and maybe even a fix.

why do you think this is a bug?  there are valid uses for restricting
access to a mounted disk.  e.g., a CDROM can be made available to a
single user even if all files on it are world readable.  if you "fix"
the bug, I would need to add an extra directory level to the mount
point.
--
Kjetil T.

Quote:> [Richard L. Hamilton]:

>>   For the Solaris 8 FCS code, the relevant source file appears to be
>>   src/uts/common/fs/lookup.c; that's about all I can say
>>   here...hopefully one of the Sun guys (Casper, where are you???)
>>   will take the hint, file a bug, and maybe even a fix.

> why do you think this is a bug?  there are valid uses for restricting
> access to a mounted disk.  e.g., a CDROM can be made available to a
> single user even if all files on it are world readable.  if you "fix"
> the bug, I would need to add an extra directory level to the mount
> point.

And the reason you'd want lookups of (not even access to, just lookups of)
".." to fail in the top level of a mounted CD-ROM (or whatever) is ...
what?  That's what's happening if the underlying mount-point directory
doesn't have execute access to the process's creds, and what breaks pwd.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

[Richard L. Hamilton]:

Quote:

>   [Kjetil Torgrim Homme]:
>   > why do you think this is a bug?  there are valid uses for
>   > restricting access to a mounted disk.  e.g., a CDROM can be made
>   > available to a single user even if all files on it are world
>   > readable.  if you "fix" the bug, I would need to add an extra
>   > directory level to the mount point.

>   And the reason you'd want lookups of (not even access to, just
>   lookups of) ".."

(what's the difference between a lookup and an access?)

Quote:>   to fail in the top level of a mounted CD-ROM (or whatever) is ...
>   what?

it's the way Unix works.

Quote:>   That's what's happening if the underlying mount-point directory
>   doesn't have execute access to the process's creds, and what
>   breaks pwd.

don't do that, then.
--
Kjetil T.