Re: securety related question...

On Mon, 7 Oct 2002, Erika Pacholleck wrote:

> [06.10.2002] Bill maltby - LFS Related <-- :
> > On Sun, 6 Oct 2002, Erika Pacholleck wrote:
> > > suddenly a by intention mounted ro partition will be rw, and what you
> > > believe protected by ro is suddenly deleted via the bound mounting point!
> > 
> > So? I see no problem with that. Further, it is no different than current
> > (flawed) *IX implementations for directories. Have some fun, try this.
> > 
> > Cd to some directory. From another session, rm -rf the directory in whcich
> > the other is positioned. Now go to the first session again. Do pwd. Then
> > do "cd ..". Interesting?
> 
> What do you mean by that?
> Should I be suprised that bash seems to store the cd'ed path and returns it
> although that directory had been deleted from another session?
> Try `pwd -P` and `/bin/pwd` instead ;)
> 
> Rather a bash matter than flawed directory implementations, or?
> 

I should have been more explicit in my intent.

Given this directory structure

    /tmp
       /todel
            /todel2

One process changes directory as follows

    cd /tmp/todel/todel2

Another process does rm -rf /tmp/todel. The first process now does

    cd ..

The result is

    cd: could not get current directory
    cd: could not get current directory

After the pwd -P, the result of a cd .. is

   cd_links: could not get current directory

Obviously not a bash flaw - it does not have file-system notification
capability. But the kernel *is* aware of these things. The problem is that
it has allowed removal of a directory structure that invalidates the cwd
of an active process. For mounts, there is a "use count" that prevents
unmounting an "active" file system. This is with good reason.

I have always considered the failure of the kernel to provide a similar
protection for "active" directory paths to be a flaw either in design or
implementation. The net effect of the above example is to invalidate the
environment of a properly operating process. Although I have not invest-
igated the potential, I think that it might also provide opportunity for a
security breach.

Every *IX I have worked on has had this weakness. One would think that
after all these years, all implementations would have remedied this
situation.

-- 
Bill Maltby
[email protected]

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