Re: odd behaviour of "pwd" & "df" after Live Upgrade?
Richard L. Hamilton
"G. Low" <donotreplayATnowhereDOTcom> writes:
> 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).
--
mailto:rlh...@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
John S.
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....
Richard L. Hamilton
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.
Darren Dunham
>>> > 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.
--
Darren Dunham ddu...@taos.com
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. >
Richard L. Hamilton
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
Darren Dunham
> Seems ok now:
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
Darren Dunham
> 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...
Rusty Wright
Unix has always behaved this way; if the directory a filesystem is
mounted on has restrictive permissions then pwd can fail.
Richard L. Hamilton
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!
Richard L. Hamilton
Rusty Wright <ru...@socrates.Berkeley.EDU> writes:
> 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.
Richard L. Hamilton
> 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.
Richard L. Hamilton
Richard.L...@mindwarp.smart.net (Richard L. Hamilton) writes:
> In article <10iqeks...@corp.supernews.com>,
> Richard.L...@mindwarp.smart.net (Richard L. Hamilton) writes:
> [...]
>> 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.
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.
Kjetil Torgrim Homme
>
> 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.
Richard L. Hamilton
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.
Kjetil Torgrim Homme
>
> [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?)
> to fail in the top level of a mounted CD-ROM (or whatever) is ...
> what?
it's the way Unix works.
> 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.
Darren Dunham
I don't follow. How does the behavior we've described restrict access
to a mounted disk? It doesn't appear to affect access to the data on
the disk at all.
Richard L. Hamilton
>>
>> [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?)
ls -ld .. # just lstat() the damn thing and report the results
ls -l .. # lstat() it, if it's a directory, open the directory, do a
# readdir(), etc.
Because the permissions of the underlying directory are applied when
attempting to [l]stat() .. in a top-level directory of a mounted
filesystem, if the underlying directory doesn't have execute permission,
even the [l]stat() fails. I don't see why anyone would _want_ that;
one can typically live with it, but it's obnoxious.
>> to fail in the top level of a mounted CD-ROM (or whatever) is ...
>> what?
>
> it's the way Unix works.
>
>> 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.
Yeah, the universal work around: "Doctor, it hurts when I do this".
"Well, don't do it then".
Chris Thompson
> Kjetil Torgrim Homme <kjet...@yksi.ifi.uio.no> writes:
>> [Richard L. Hamilton]:
>>> 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.
>
>Yeah, the universal work around: "Doctor, it hurts when I do this".
>"Well, don't do it then".
You do realise that you are proposing to deprive me of one of my
favourite trick questions for wannabe Unix[*] system administrators?
[*] Well, Solaris, anyway. I haven't checked other Unix flavours
for this particular "feature" recently.
Chris Thompson
Email: cet1 [at] cam.ac.uk
Casper H.S. Dik
It doesn't really restrict access to mount points; all it does it
prevent "pwd" from working.
It's arguably a bug in the SunOS/Solaris VFS layer but it's also one
of the trivia facts that separates the men from the boys :-)
Casper
Richard L. Hamilton
Well, I for one think it is a bug.
But to be fair, I wanted to see how far back it was a problem.
The oldest thing I had available was Unix v7 on a PDP-11 emulator.
Sure enough, it had the problem too.
So, at least it's a problem with history. I wonder why I've never
run into it before now? Maybe just never occurred to me to install
anything with umask set more restrictive than 022.
Kjetil Torgrim Homme
>
> [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.
>
> I don't follow. How does the behavior we've described restrict
> access to a mounted disk? It doesn't appear to affect access to
> the data on the disk at all.
oops. I was sure it would restrict access to processes wanting to
enter the mount point, but at least in Solaris 9 it has no other
effect than restricting access to "..". I don't see a way to call
this a feature. sorry for the inconvenience.
--
Kjetil T.