Re: securety related question...

On Mon, 7 Oct 2002, Erika Pacholleck wrote:
> [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.

I think we are talking apples and oranges here. I'm doing what a user
(or normal shell script) would normally do. That is "ls", "pwd" and so on
with no braces, no special bash interpretation. I think the results we get
are incorrect in that *I* expect when things can not find either the
current directory or any *needed* part of the path leading to it, it
should *only* issue an error message and set a bad return, not do
something that could fool a user into thinking all was OK. The ls showing
the contents of the last part of the path is an example of this.

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

Being a C programmer, I know that we can code in such a way that I could
produce some kind of results and say that the ouput was correct for what I
intended. But, that does not mean the "system" behaviour is correct. The
point of my statements is that when a directory structure has been
removed, all references to any removed part of the path that does not
produce an error message (optionally?) and/or does not return a fail
return code is an error. Since in my example, the system does not
consistently do this, I consider it an error.

Someone else may view this behaviour as acceptable and we can all produce
constructs that may work "in certain ways" by causing different path
processing to be done. And I have no knowledge if the behaviour in the
examples you gave is different with various releases of the kernel or the
various utilities.

>   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!

No - I had not mentioned that prior to the previous post. As with many
designs, we have begun the progression from "more general to more
detailed". When you mentioned the possible pitfalls, then the natural
"next step" was to address that by saying "... how can this be
prevented?". So in the previous post, when I responded, I stashed that new
consideration in there. Then at the bottom, since I had mentioned it
above, I just referenced it.

> > And, I would ask only behavior consistent with the rest of the system
> > (which I would like to be more "correct").
> 
> Agreed.
> 

-- 
Bill Maltby
[email protected]

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message