Re: securety related question...

[07.10.2002] Bill maltby - LFS Related <-- :
> On Mon, 7 Oct 2002, Erika Pacholleck wrote:
  8<--- 
> 
> ?? On my system (LFS 4.0), both pwd -P, echo $PWD return the same thing.
> If they are done *before* the cd .., they both show the expected path. If
> done *after* the cd .., they both show the same error message. So, I say
> it is not a bash problem because the independent /bin/pwd returns the same
> as bash's builtin echo. It is a kernel or library problem.
> 
> Further, another twist is added if you look at ls's (and other utility
> commands) behavior before and after the "cd ..". Before the "cd ..", "ls
> -a .." returns nothing and sets a "success" return code. This is an error.
> After the "cd ..", "ls -a .." returns the contents of the last level of
> the directory it could successfully process. This could be considered
> correct, from the programmers view. 
  8<--- 
it's long enough, so return codes as command{$?}, PS1="\u[\l]:\w "

albert[3]:~ mkdir -p see/how/this; touch see/how/this/behaves; ls{0}
Mail files see tmp

albert[3]:~ cd see/how/this/; ls{0}
behaves
albert[3]:~/see/how/this pwd{0}; pwd -P{0}; /bin/pwd{0}
/home/albert/see/how/this
/home/albert/see/how/this
/home/albert/see/how/this

albert[4]:~ rm -rf see/
albert[3]:~/see/how/this ls{0} <---0 discussable
albert[3]:~/see/how/this pwd{0}; pwd -P{1}; /bin/pwd{1}
/home/albert/see/how/this
/bin/pwd: cannot get current directory: no such file or directory

albert[3]:~/see/how/this cd ..{0} <---should be in see/how afterwards
cd: could not get current directory: ...more text
cd: could not get current directory: ...more
albert[3]:. ls{0} <---0 contradictive to error message
job-working-directory: could not get current directory: ...more
albert[3]:. pwd{1}; pwd -P{1}; /bin/pwd{1}
pwd: could not get current directory: ...more text
pwd: could not get current directory: ...more text
job-working-directory: could not get current directory: ...more
/bin/pwd: cannot get current directory: no such file or directory

albert[3]:. cd ../..{0} <---should be in ~ afterwards
chdir: could not get current directory: ...more
albert[3]:../.. ls{0}
Mail files tmp <---this is the correct list of alberts home
albert[3]:../.. pwd{0}; pwd -P{0}; /bin/pwd{0}
../../         <---this is bash pwd and nonsense
.              <---this is bash pwd -P
/home/albert   <---this is /bin/pwd and correct

albert[3]:../.. cd ../..{0} <---should be in / afterwards
albert[3]:../../../.. ls{0}
bin boot dev etc home lib ... <---is correct
albert[3]:../../../.. pwd{0}; pwd -P{0}; /bin/pwd{0}
../../../..    <---bash pwd
.              <---bash pwd -P
/              <---/bin/pwd and it is correct

albert[3]:../../../.. cd home/albert{0}
albert[3]:../../../../home/albert ls{0}
Mail files tmp <---this is the correct list of alberts home
albert[3]:../../../../home/albert pwd{0}; pwd -P{1}; /bin/pwd{0}
../../../../home/albert <---again bash is wrong
/home/albert            <---and /bin/pwd correct

albert[3]:../../../../home/albert cd see{1}
bash: cd: see: no such file or directory

So far this system, admitted not 100% book built, not 4.0 (is in work)
glibc-2.2.5, gcc-3.0.4, bash-2.05a, sh-utils-2.0, alpha.fileutils-4.1.6
linux-2.4.19-pre1 (full list available)

> > And unfortunately an ancient /bin/cd was given up because "every shell
> > is expected to have it integrated" (I am implementing here that an
> > independent /bin/cd would be able to work according to /bin/pwd).
> 
> But it would not. Here is the deal. Regardless of integration, when a "cd
> .." is done, the utility must read the current directory (unless is saved
> it) and get the entry for "..". This will give an i-node that can then be
> used to "open" the referenced directory. But, in the example I gave, that
> directory no longer exists. So an independent "cd" would behave like the
> current "cd" or "ls" and so on. Its only option is if it saved previous
> path-component information. Then it could say "I don't have a valid ..,
> I will go to the last valid component I know about". It might give a
> message so the user would be aware.

But my cd and ls and /bin/pwd do the correct thing!
cd returns 0 which is correct because it *does* do cd to where I tell it
ls shows the contents correct if there one, return values need watching
/bin/pwd shows the correct path if it is valid and return values are
correct and in harmony with error messages.

So if *they* can do it, what is so difficult for a /bin/cd?
And then please watch what mess bash produces.

  8<---
> I think a policy of "--bind with same or more restrictive permssions but
> not less restrictive..." would work just fine.
  8<---
> Yes. But as above, I would *not* advocate less restrictive --bind
> mounts. Only same/more restrictive options.

Did you say that anywhere I did not see it? Now imagine, I could live
with that!
 
> And, I would ask only behavior consistent with the rest of the system
> (which I would like to be more "correct").

Agreed.
-- 
Erika ...---...: pacholleck at nexgo dot de
-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message