Prev: setuid question - permission denied
Next: Simple hack to get $500 to your home
From: Maxwell Lol on 10 Jun 2010 20:00
> I know but I would like to know if that is a bash bug (so should I
> report it?) or not (because it is already known)

If any process has a current directory that is deleted, then how can
it know where its current directory is?

What do you expect it to answer?

and if the current directory is unknown, what should ../ mean?

From: Jon LaBadie on 10 Jun 2010 23:06
Maxwell Lol wrote:
>> I know but I would like to know if that is a bash bug (so should I
>> report it?) or not (because it is already known)
>
> If any process has a current directory that is deleted, then how can
> it know where its current directory is?
>
> What do you expect it to answer?
>
> and if the current directory is unknown, what should ../ mean?
>

Hmmm, for ordinary files, if they are removed while open, the processes
already using the file can continue to use them. I wonder why the
behavior for a removed directory is different than for an open file
which is removed. Isn't there a reference count in the incore version
of the inode tracking how many processes are using the directory?
From: Maxwell Lol on 11 Jun 2010 06:52
Jon LaBadie <jlabadie(a)aXcXm.org> writes:

> Maxwell Lol wrote:
>>> I know but I would like to know if that is a bash bug (so should I
>>> report it?) or not (because it is already known)
>>
>> If any process has a current directory that is deleted, then how can
>> it know where its current directory is?
>>
>> What do you expect it to answer?
>>
>> and if the current directory is unknown, what should ../ mean?
>>
>
> Hmmm, for ordinary files, if they are removed while open, the processes
> already using the file can continue to use them. I wonder why the
> behavior for a removed directory is different than for an open file
> which is removed. Isn't there a reference count in the incore version
> of the inode tracking how many processes are using the directory?

If you delete an open file, processes that were still using it can
continue to do so, because they use an open file descriptor. They
cannot tell you the "previous" name of the file, as it no longer
exists.

The entry in the directory points to an inode, not the other way
around.



From: Jon LaBadie on 11 Jun 2010 10:38
Maxwell Lol wrote:
> Jon LaBadie <jlabadie(a)aXcXm.org> writes:
>
>> Maxwell Lol wrote:
>>>> I know but I would like to know if that is a bash bug (so should I
>>>> report it?) or not (because it is already known)
>>> If any process has a current directory that is deleted, then how can
>>> it know where its current directory is?
>>>
>>> What do you expect it to answer?
>>>
>>> and if the current directory is unknown, what should ../ mean?
>>>
>> Hmmm, for ordinary files, if they are removed while open, the processes
>> already using the file can continue to use them. I wonder why the
>> behavior for a removed directory is different than for an open file
>> which is removed. Isn't there a reference count in the incore version
>> of the inode tracking how many processes are using the directory?
>
> If you delete an open file, processes that were still using it can
> continue to do so, because they use an open file descriptor. They
> cannot tell you the "previous" name of the file, as it no longer
> exists.
>
> The entry in the directory points to an inode, not the other way
> around.
>

The user area (block?) of a process contains the open file table.
Each entry in the array is a pointer that can be used to get to
the incore inode of the open file. Also in the user area are
pointers that are used to access the incore inode of the root
and current directories of the process.

I'm probably being dense, but I fail to see why a process can
access the data of a deleted open file using the pointer in the
user area but can not access the data of the removed current
directory using a similar user area pointer. I can see that
it happens, I can understand that the system does make the
directory unavailable after it is removed, but I don't
understand why. What is different about a removed open file
and a removed current directory?

Perhaps the behavior is different to prevent creation of
files in the deleted current directory which would be
orphaned after the process dies or changes directory.
But I expect things like that could be accounted for.




From: Seebs on 11 Jun 2010 11:47
On 2010-06-11, Jon LaBadie <jlabadie(a)aXcXm.org> wrote:
> I'm probably being dense, but I fail to see why a process can
> access the data of a deleted open file using the pointer in the
> user area but can not access the data of the removed current
> directory using a similar user area pointer.

And what data, exactly, are you expecting to find for the directory?

It no longer has a . or .. entry, so there's no way to look at its ..;
that file ceased to exist.

".." isn't some kind of special magic that is secretly translated into
"my parent directory" later. It's a hard link to the parent directory.
If you remove the ".." entry (which you do, when you rmdir), there is
no way to meaningfully describe anything as the "parent" directory
anymore.

When you unlink a still-open file, the file has *contents* which you
can still access, but does not have a *path*. But directories are nothing
but path; when you take a way the path, there's nothing there anymore.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: setuid question - permission denied
Next: Simple hack to get $500 to your home