Prev: setuid question - permission denied
Next: Simple hack to get $500 to your home
From: Alan Curry on 15 Jun 2010 18:25
In article <7c26b84b-8c89-4ec8-a83c-eb0d6f972d8d(a)x21g2000yqa.googlegroups.com>,
Javi Barroso <javibarroso(a)gmail.com> wrote:
>
>But seems like something doesn't work like expected:
>~/test/test2$ # continuing with the example
>~/test/test2$ cd ..
>..$ ls
>..$ cd ..
>../..$ ls # should I be here in ~ ?
>user1 user2 user3 ... userN
>
>Well, After all, Simply don't remove cwd, that is a stupid thing :-)

Using cd -P would make this behave better. If you always use cd -P, things
will definitely make sense. Without -P, the shell tries to be smart and
sometimes fails. It's hard to be smart about cd'ing into a parent directory
that has been removed.

--
Alan Curry
From: Maxwell Lol on 16 Jun 2010 08:06
Javi Barroso <javibarroso(a)gmail.com> writes:

>> > in '/' is '/' isn't it ? It is ugly have ../../../../../ #
>> > as current pwd, isn't it ?
>>
>> I don't understand. I've never seen this when I do a pwd.
>
> You can see that in my example (in the first post)


Okay. Gotcha.

Okay - there is a large difference between pwd (and what the kernal
state of the process knows), and what a shell's prompt does, based on
the shell's knowledge. pwd will not display ".." Your prompt might
display ".."

The the problem is not in pwd, but in how the prompt is displayed,
right? And the prompt is under the user's control.

I am not an expert in advanced bash prompt-mangling. But generally
you override the commands that change the current directory, and
when this is executed, you change the prompt to the appropriate value.

Perhaps you need to override the rmdir function so that when it is
executed, the prompt is reset so it no longer displays invalid
information.

By the way, when I try to execute
rmdir .
I get "Invalid argument."
However
rmdir `pwd`
and
rmdir ../currentdirectory
execute normally.

So this is somewhat inconsistent. Perhaps the best solution is to
override the function of rmdir so that if it tries to remove the
current directory, the shell complains.

>Well, After all, Simply don't remove cwd, that is a stupid thing :-)

Well, yes. And this change would solve that problem as well. :-)
From: Javi Barroso on 16 Jun 2010 14:08
On Jun 16, 2:06 pm, Maxwell Lol <nos...(a)com.invalid> wrote:
> Javi Barroso <javibarr...(a)gmail.com> writes:
> >> > in '/' is '/' isn't it ? It is ugly have ../../../../../ #
> >> > as current pwd, isn't it ?
>
> >> I don't understand. I've never seen this when I do a pwd.
>
> > You can see that in my example (in the first post)
>
> Okay. Gotcha.
>
> Okay - there is a large difference between pwd (and what the kernal
> state of the process knows), and what a shell's prompt does, based on
> the shell's knowledge.  pwd will not display ".."  Your prompt might
> display ".."
No, pwd display ".." in this case :( (at least in my debian box), but
forgot it, this is a stupid question, thought I think this issue
should be solved in bash future releases somehow

Thanks for your opinions!
From: Robert Bonomi on 2 Jul 2010 12:25
In article <2d13ac43-45c4-4106-ac00-1916dc657d70(a)g19g2000yqc.googlegroups.com>,
Javi Barroso <javibarroso(a)gmail.com> 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)

NO it is *NOT* a bug. it happens exactly the same way in evry shell, and
has for 30 years.

It is a _predictable_result_ of 'user idiocy'.

The thing that needs to be fixed is the user.


From: Robert Bonomi on 2 Jul 2010 13:25
In article <hutnqv$d6s$1(a)news.eternal-september.org>,
Jon LaBadie <jlabadie(a)aXcXm.org> wrote:
>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.

The short answer is "directories are special".

Unlike a file, you cannot delete a directory, *IF* it -has- any 'contents'.
To delete a non-empty directory (e.g. the 'rdir -f' weapon), it first deletes
any/all files in the directory and then deletes the directory. ('rmdir -f'
fails if there is a directory in the directory.)

A directory with _only_ ".", and ".." in it, is considered "empty",
and rmdir *does* -remove- those "contents" before removing the name entry.

deleting a directory involves:
1) looking for any content *OTHER*THAN* '.' and '..'
2) _if_ found, refusing to remove the directory.
3) if _nothing_ found,
REMOVE the 'pseudo entries' for '.' and '..'
4) THEN, and only then, unlink the name of the file/directory.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: setuid question - permission denied
Next: Simple hack to get $500 to your home