Prev: setuid question - permission denied
Next: Simple hack to get $500 to your home
From: Jon LaBadie on 11 Jun 2010 12:21
Seebs wrote:
> 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.
>

As the *contents* of a directory (i.e. its data blocks) are basically
name and inode number pairs, the ".." entry still has an inode number
associated with it. You chdir to that directory with a full path
that eventually resolves to the parent's inode. Why wouldn't the
same inode number associated with ".." get you there - if the
deleted current directory's data were still available as a deleted
open file's data are still available.
From: Ben Bacarisse on 11 Jun 2010 13:42
Jon LaBadie <jlabadie(a)aXcXm.org> writes:

> Seebs wrote:
>> 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.
>>
>
> As the *contents* of a directory (i.e. its data blocks) are basically
> name and inode number pairs, the ".." entry still has an inode number
> associated with it. You chdir to that directory with a full path
> that eventually resolves to the parent's inode. Why wouldn't the
> same inode number associated with ".." get you there - if the
> deleted current directory's data were still available as a deleted
> open file's data are still available.

I think this theory relied on the program (the shell i this case, I
think) holding the directory open. I doubt it does so.

--
Ben.
From: Wayne on 11 Jun 2010 17:01
On 6/10/2010 8:09 AM, Javi Barroso 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)
>
> Thanks

This is not a bug, and not a Bash issue at all. I just looked it up
on POSIX for rmdir and found this:

If the directory is the root directory or the current working directory of any
process, it is unspecified whether the function succeeds, or whether it shall
fail and set errno to [EBUSY].

I would prefer this to fail with EBUSY but it doesn't on Linux; the
directory just goes away..

--
Wayne
From: Alan Curry on 11 Jun 2010 18:37
In article <slrni14mkp.i2b.usenet-nospam(a)guild.seebs.net>,
Seebs <usenet-nospam(a)seebs.net> wrote:
>
>".." isn't some kind of special magic that is secretly translated into
>"my parent directory" later.

Unless you're using Linux 2.2 or greater... then that's exactly what it is.

$ ls -f
.. ..
$ cat ../file
this is the content of file
$ rmdir `pwd`
$ ls -f
$ cat ../file
this is the content of file
$ cd ..
$ cat file
this is the content of file
$

--
Alan Curry
From: Seebs on 11 Jun 2010 20:03
On 2010-06-11, Jon LaBadie <jlabadie(a)aXcXm.org> wrote:
> As the *contents* of a directory (i.e. its data blocks) are basically
> name and inode number pairs, the ".." entry still has an inode number
> associated with it.

Except it was removed. That ".." entry no longer exists. The directory
you "still have open" (if you could do this) would not *contain* a ".."
entry.

> You chdir to that directory with a full path
> that eventually resolves to the parent's inode. Why wouldn't the
> same inode number associated with ".." get you there - if the
> deleted current directory's data were still available as a deleted
> open file's data are still available.

Because there's no "there". All the ways of talking about directories and
paths are, somewhere in there, rooted in the notion of a path. Once the
directory is gone, it hasn't got a path.

-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