Re: [PATCH] Add a /proc/self/exedir link

Re: [PATCH] Add a /proc/self/exedir link

[Bodo Eggert]

Neil Brown <neilb@suse.de> wrote:
> On Tuesday April 4, mike@plan99.net wrote:

>> To clarify, I'm proposing this patch for eventual mainline inclusion.
>> 
>> It adds a simple bit of API - a symlink in /proc/pid - which makes it
>> easy to build relocatable software:
>> 
>>    ./configure --prefix=/proc/self/exedir/..

[...]

> It strikes me that this is very fragile.  If the application calls
> anything out of /bin or /usr/bin etc passing a path name which works
> for the application, it will break for the helper.

ACK.

> It also requires all binaries use by the application to live in the
> same directory.  This would be OK  for some applications, but not for
> everything.
> 
> It sounds to me like you want a private, inherited, name space, and
> Linux provides those via CLONE_NEWNS, however you probably need root
> access to make that work, which isn't ideal.

This isn't going to rock either. If process A links
$PID->namespace:/const/exedir/ to /mnt/net/host_a/foo/bin and passes
/const/exedir/../lib/foo to process B, this process B must not
link it's $PID->namespace:/const/exedir/ to e.g. /opt/B/bin, but
exactly this is going to happen if you use a constant string.

> I think you'd have move luck (ab)using an environment variable.
> Make
>    /proc/self/env_prefix
> be a symlink pointing to whatever the "PREFIX" environment variable
> stores.

Same problem.


IMO the program must be aware of the get-my-exedir feature, just configuring
--prefix=/proc/... is aiming for your feet.

/proc/pid/exedir may be a way to access the program files after changing the
namespace, but it may also be a security risk leaving the original namespace
accessible. Therefore I suggest abandoning the exedir idea and instead

1) change the programs to be aware of it's exedir:
   (my $exedir=`cat /proc/self/exe`) =~ s,/[^/]+$,,);
   if ($libdir !~ m,^/,) { $libdir = $exedir.'/'.$libdir };
 - or -
   ln -s /mnt/net/host_a/foo /usr/local/foo
   (cd /usr/local/bin && for a in ../foo/bin; do ln -s "$a";done)
2) If you want access across namespaces, use fopen etc. on an open
   directory handle
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

> IMO the program must be aware of the get-my-exedir feature, just configuring
> --prefix=/proc/... is aiming for your feet.

I disagree, though /proc/self/exedir may not be the right answer. The 
problem with the original proposal is there's no concept of a group 
leader to which files are resolved relative to so there is this problem 
with child processes.

I sent a mail outlining a scheme that used file descriptor passing to 
achieve the same effect but with the needed "inheritance" of the path, 
but, vger seems to have munched it! At least I don't see it on the gmane 
archives. But the scheme is simple enough:

  * get_prefix() reads /proc/self/exe and turns it into the correct
    directory

  * dup2(open(get_my_exedir()), 999)

  * ./configure --prefix=/proc/self/fd/999

Obviously that code leaks but you get the idea. Paths can now be 
resolved relative to the magic fd number (whatever numbe is used up to 
the userspace app). The fd is inherited on exec, so sub-programs that 
are passed a path relative to it still work.

It doesn't need kernel support which is nice.

It also restricts the problem to passing paths to other processes that 
are not subprocesses (eg via rpc). But as each process can have its own 
namespace this will always be an issue that needs careful treatment, and 
the pain of adjusting software to realpath() it is much lower than 
modifying every path in every piece of software. That approach was 
already tried and sucks.

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Bodo Eggert]

On Thu, 6 Apr 2006, Mike Hearn wrote:

> > IMO the program must be aware of the get-my-exedir feature, just configuring
> > --prefix=/proc/... is aiming for your feet.
> 
> I disagree, though /proc/self/exedir may not be the right answer. The 
> problem with the original proposal is there's no concept of a group 
> leader to which files are resolved relative to so there is this problem 
> with child processes.

The problem ist the word 'the'. If parent and child are using 'the foo',
they will clash.

> I sent a mail outlining a scheme that used file descriptor passing to 
> achieve the same effect but with the needed "inheritance" of the path, 
> but, vger seems to have munched it! At least I don't see it on the gmane 
> archives. But the scheme is simple enough:
> 
>   * get_prefix() reads /proc/self/exe and turns it into the correct
>     directory
> 
>   * dup2(open(get_my_exedir()), 999)
>
>   * ./configure --prefix=/proc/self/fd/999

bin/foo calls bin/bar refering to /proc/self/fd/999
bin_2/bar does dup2(open(get_my_exedir()), 999)  ***FUBAR***

possible solution:

don't dup2, and only close fds you opened yourself.

Disadvantage: Leaky (too), may break scripts.

.oO(Can you chroot a single filedescriptor or somehow make 
    /proc/self/fd/$n/.. be unavailable?)

> It also restricts the problem to passing paths to other processes that 
> are not subprocesses (eg via rpc). But as each process can have its own 
> namespace this will always be an issue that needs careful treatment, and 
> the pain of adjusting software to realpath() it is much lower than 
> modifying every path in every piece of software. That approach was 
> already tried and sucks.

There may be no "real path" corresponding to /proc/self/fd/4711.

IMO it's still best to just symlink the program directory to the correct 
place and make the programs search in e.g. ~/opt/ and /opt/.
-- 
Fun things to slip into your budget
An abacus

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

> bin/foo calls bin/bar refering to /proc/self/fd/999
> bin_2/bar does dup2(open(get_my_exedir()), 999)  ***FUBAR***

So don't do that. Treat it as the same case as sending a file path via 
RPC: make sure it's resolved relative to the namespace the program is in 
and not anything under /proc/self.

In practice most desktop apps use "prefix paths" to locate their own 
data files. They don't usually send those file paths to other processes, 
not even in the case of things like GIMP plugins.

So whilst I agree you have identified a place where it breaks, I don't 
think it invalidates the scheme.

> There may be no "real path" corresponding to /proc/self/fd/4711.

Only in a pathological case like running a program that you then rm -rf 
the prefix of, in which case, you lose whatever happens.

> IMO it's still best to just symlink the program directory to the correct 
> place and make the programs search in e.g. ~/opt/ and /opt/.

That also suffers from namespace conflicts ;)

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Eric W. Biederman]

Mike Hearn <mike@plan99.net> writes:

> In practice most desktop apps use "prefix paths" to locate their own data
> files. They don't usually send those file paths to other processes, not even in
> the case of things like GIMP plugins.

Programs that ssh to another machine and run commands are likely
to send paths.

>> IMO it's still best to just symlink the program directory to the correct place
>> and make the programs search in e.g. ~/opt/ and /opt/.
>
> That also suffers from namespace conflicts ;)


I looked at your original proposal some more and it fails
miserably for shell scripts.  Basically they all get / as
their prefix, no matter where in the filesystem you put them.

Also there is a very serious problem with suid exectuables.
If a non privileged user has write access to the same filesystem
the exectuables live on they can create a hard link to those
files and change the prefix.  Quite possibly getting the suid
executables to trust a new set of exectuables.

So this scheme appears to have many if not all of same security issues
as private namespaces.

Given that mostly it will be junior programmers packaging applications
behind the backs of the authors of the code that will implement this
scheme we could introduce all kinds of problems that no one will
notice for quite a while.

Eric

Fwd: [PATCH] Add a /proc/self/exedir link

[Joshua Hudson]

> Also there is a very serious problem with suid exectuables.
> If a non privileged user has write access to the same filesystem
> the exectuables live on they can create a hard link to those
> files and change the prefix.  Quite possibly getting the suid
> executables to trust a new set of exectuables.

Excellent point. This proposal needs to die, but there needs to be some way
to solve this problem.

Re: Fwd: [PATCH] Add a /proc/self/exedir link

[John Stoffel]

>>>>> "Joshua" == Joshua Hudson <joshudson@gmail.com> writes:

Joshua> Excellent point. This proposal needs to die, but there needs
Joshua> to be some way to solve this problem.

Why don't you try to explain the problem in more depth, but without
assuming a solution at all.  Just talk about what you're trying to
fix.  

As a SysAdmin by trade, if the program is written sanely, it's not
hard to make it relocateable and runable from anywhere.  It's when the
program *knows* or the libraries is uses *know* that stuff is in
certain locations that things break.  

I'm really writing from memory here, since I first saw your proposal
and looked it over and went "why bother?" but didn't have the time to
check it out in detail.  

John

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

Eric W. Biederman wrote:
>> In practice most desktop apps use "prefix paths" to locate their own data
>> files. They don't usually send those file paths to other processes, not even in
>> the case of things like GIMP plugins.
> 
> Programs that ssh to another machine and run commands are likely
> to send paths.

I'm confused again, sorry, these paths would be on the remote machine in 
such a case surely?

> I looked at your original proposal some more and it fails
> miserably for shell scripts.  Basically they all get / as
> their prefix, no matter where in the filesystem you put them.

There is no good way for a shell script to find out where it is, that's 
always been true on Linux and fixing it wasn't a goal of the patch as it 
can be easily done in userspace using a little stub program.

It'd definitely be nice to fix it though.

> Also there is a very serious problem with suid exectuables.
> If a non privileged user has write access to the same filesystem
> the exectuables live on they can create a hard link to those
> files and change the prefix.  Quite possibly getting the suid
> executables to trust a new set of exectuables.

Yes. I don't think that can be fixed in a general way. Again I guess the 
solution would be "don't do that". Maybe the patch could be adapted so 
/proc/self/exedir is not available for suid root programs, to stop 
people making that mistake. Ditto for the fd passing scheme.

> Given that mostly it will be junior programmers packaging applications
> behind the backs of the authors of the code that will implement this
> scheme we could introduce all kinds of problems that no one will
> notice for quite a while.

I guess you are referring to autopackages - whilst simplifying 
relocatability will certainly help junior programmers build such things, 
they're designed to be built or maintained by the original authors of 
the programs themselves (unlike other package formats). Because anybody 
can build them on their own systems, they can be treated like source 
tarballs and maintained as a team.

Allowing packages to be correctly built taking into account the 
subtleties of the software was one of the motivations behind developing 
autopackage ...

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Jan Engelhardt]

>>> It leaks information about the parts of the pathname below the
>>> directory that you otherwise would not be able to see.  E.g. if
>>> I have $HOME/top-secret-projects/secret-code-name1/binary
>>> where the top-secret-projects directory isn't readable by you,
>>> then you may find out secret-code-name1 by reading the
>>> /proc/{pid}/exedir symlink.
>>
>> But we already have /proc/{pid}/exe which is a symlink to the
>> executable, thus exposing all the directory names already.

In which case the administrator of the machine should make /proc/xyz
directories mode 0700. (Patches are floating around.)


Jan Engelhardt
-- 

Re: [PATCH] Add a /proc/self/exedir link

[Eric W. Biederman]

Andreas Schwab <schwab@suse.de> writes:

> Neil Brown <neilb@suse.de> writes:
>
>> On Thursday April 6, tony.luck@gmail.com wrote:
>>> > > I have concerns about security policy ...
>>> >
>>> > I'm not sure I understand. Only if you run that program, and if you
>>> > don't have access to the intermediate directory, how do you run it?
>>> 
>>> It leaks information about the parts of the pathname below the
>>> directory that you otherwise would not be able to see.  E.g. if
>>> I have $HOME/top-secret-projects/secret-code-name1/binary
>>> where the top-secret-projects directory isn't readable by you,
>>> then you may find out secret-code-name1 by reading the
>>> /proc/{pid}/exedir symlink.
>>
>> But we already have /proc/{pid}/exe which is a symlink to the
>> executable, thus exposing all the directory names already.
>
> Neither of which should be readable by anyone but the owner of the
> process, which is the one who was able to read the secret directory in the
> first place.

In most cases.  It is possible you got the executable through
file descriptor passing and the like.

The security check in -mm allows anyone who may ptrace the
process to have read access.  In 2.6.17-rc1 the check is
still the owner of the process and anyone with CAP_DAC_ACCESS
may read or use the link.

Eric

Re: [PATCH] Add a /proc/self/exedir link

[Andreas Schwab]

Neil Brown <neilb@suse.de> writes:

> On Thursday April 6, tony.luck@gmail.com wrote:
>> > > I have concerns about security policy ...
>> >
>> > I'm not sure I understand. Only if you run that program, and if you
>> > don't have access to the intermediate directory, how do you run it?
>> 
>> It leaks information about the parts of the pathname below the
>> directory that you otherwise would not be able to see.  E.g. if
>> I have $HOME/top-secret-projects/secret-code-name1/binary
>> where the top-secret-projects directory isn't readable by you,
>> then you may find out secret-code-name1 by reading the
>> /proc/{pid}/exedir symlink.
>
> But we already have /proc/{pid}/exe which is a symlink to the
> executable, thus exposing all the directory names already.

Neither of which should be readable by anyone but the owner of the
process, which is the one who was able to read the secret directory in the
first place.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Add a /proc/self/exedir link

[Neil Brown]

On Thursday April 6, tony.luck@gmail.com wrote:
> > > I have concerns about security policy ...
> >
> > I'm not sure I understand. Only if you run that program, and if you
> > don't have access to the intermediate directory, how do you run it?
> 
> It leaks information about the parts of the pathname below the
> directory that you otherwise would not be able to see.  E.g. if
> I have $HOME/top-secret-projects/secret-code-name1/binary
> where the top-secret-projects directory isn't readable by you,
> then you may find out secret-code-name1 by reading the
> /proc/{pid}/exedir symlink.

But we already have /proc/{pid}/exe which is a symlink to the
executable, thus exposing all the directory names already.

NeilBrown

Re: [PATCH] Add a /proc/self/exedir link

[Tony Luck]

> > I have concerns about security policy ...
>
> I'm not sure I understand. Only if you run that program, and if you
> don't have access to the intermediate directory, how do you run it?

It leaks information about the parts of the pathname below the
directory that you otherwise would not be able to see.  E.g. if
I have $HOME/top-secret-projects/secret-code-name1/binary
where the top-secret-projects directory isn't readable by you,
then you may find out secret-code-name1 by reading the
/proc/{pid}/exedir symlink.

-Tony

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

> I think if we can fix namespaces you don't have to be root to use
> them that is a superioir approach, and will cover more cases.

That would be nice. I assumed they needed root for security reasons 
rather than architectural reasons.

> I have concerns about security policy ...

I'm not sure I understand. Only if you run that program, and if you 
don't have access to the intermediate directory, how do you run it?

> This means I can not run any of your relocatable executalbes in 
 > a chroot environment unless I mount proc.

Why is mounting proc a bad thing? I have never seen a Linux distro that 
does not provide proc and many desktop-level things depend on it.

> Given how long we have been without this I doubt many people actually
> care

You could argue the same for any new feature. Writing relocatable 
software on UNIX is absolutely standard, except it's done at source 
compile time not runtime. That fits with the traditional UNIX culture of 
compiling software to install it, but the times they are a changin :)

> I'm not certain the directory of an inode even makes sense, and
> that is what you are asking for us to export.

How so? The code does work, though I guess you could devise a scenario 
in which there is a running executable that is not attached to any 
directory.

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Eric W. Biederman]

Mike Hearn <mike@plan99.net> writes:

> Alright, Andrew Morton indicated that he liked this patch but the idea needed
> discussion and mindshare. I asked Con Kolivas if it made sense to go in his
> desktop patchset for people to try: he said he liked it too but it's not his
> area, and that it should be discussed here.
>
> To clarify, I'm proposing this patch for eventual mainline inclusion.
>
> It adds a simple bit of API - a symlink in /proc/pid - which makes it easy to
> build relocatable software:
>
>    ./configure --prefix=/proc/self/exedir/..
>
> This is useful for a variety of purposes:
>
> * Distributing programs that are runnable from CD or USB key (useful for
>    Linux magazine cover disks)
>
> * Binary packages that can be installed anywhere, for instance, to your
>    home directory
>
> * Network admins can more easily place programs on network mounts
>
> I'm sure you can think of others. You can patch software to be relocatable
> today, but it's awkward and error prone. A simple patch can allow us to get it
> "for free" on any UNIX software that uses the idiomatic autotools build system.
>
> So .... does anybody have any objections to this? Would you like to see it go
> in? Speak now or forever hold your peace! :)

You patch needs to move proc_exedir_link into base.c instead
of replicating it twice (that is a maintenance problem).

I think if we can fix namespaces you don't have to be root to use
them that is a superioir approach, and will cover more cases.

I have concerns about security policy in this case because a proc
symlink is not a symlink.  So if you chmod an intermediate directory
in your prefix to 000 you will still be able to access it.

I'm not at all certain I like applications depending on the fact
that I have procfs mounted on /proc.  It's bad enough that system
libraries are beginning to care.   This means I can not run any of
your relocatable executalbes in a chroot environment unless I mount
proc.

If we add this it will never be removed from /proc, so we should
be certain we want this.

Given how long we have been without this I doubt many people actually
care, or their software would be written so it was relocatable from
day one.

I'm not certain the directory of an inode even makes sense, and
that is what you are asking for us to export.

Eric

Re: [PATCH] Add a /proc/self/exedir link

[Nix]

On 4 Apr 2006, Jan Engelhardt whispered secretively:
> No objections. We'll see what it can buy us, when we get the chance 
> to use it. If it sucks, it will find its way out again. :)

In my experience, if it sucks, it'll be part of the ABI and can't be
removed without breaking userspace code (to wit, /proc/{pid}/smaps,
whose only likely widespread user has declared it too horribly-formatted
to use (i.e. acahalan and procps), but it's still there...)

Stuff in /proc/{pid}/ doesn't die easily...

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'

Re: [PATCH] Add a /proc/self/exedir link

[Jan Engelhardt]

>  ./configure --prefix=/proc/self/exedir/..
>
> So .... does anybody have any objections to this? Would you like to see it go
> in? Speak now or forever hold your peace! :)
>

(Obligatory answer from fs/proc/base.c):
        /*
         * Yes, it does not scale. And it should not. Don't add
         * new entries into /proc/<tgid>/ without very good reasons.
         */


No objections. We'll see what it can buy us, when we get the chance 
to use it. If it sucks, it will find its way out again. :)


Jan Engelhardt
-- 

Re: [PATCH] Add a /proc/self/exedir link

[Neil Brown]

On Tuesday April 4, mike@plan99.net wrote:
> 
> To clarify, I'm proposing this patch for eventual mainline inclusion.
> 
> It adds a simple bit of API - a symlink in /proc/pid - which makes it 
> easy to build relocatable software:
> 
>    ./configure --prefix=/proc/self/exedir/..
> 
> This is useful for a variety of purposes:
> 
> * Distributing programs that are runnable from CD or USB key (useful for
>    Linux magazine cover disks)
> 
> * Binary packages that can be installed anywhere, for instance, to your
>    home directory
> 
> * Network admins can more easily place programs on network mounts
> 
> I'm sure you can think of others. You can patch software to be 
> relocatable today, but it's awkward and error prone. A simple patch can 
> allow us to get it "for free" on any UNIX software that uses the 
> idiomatic autotools build system.
> 
> So .... does anybody have any objections to this? Would you like to see 
> it go in? Speak now or forever hold your peace! :)

It strikes me that this is very fragile.  If the application calls
anything out of /bin or /usr/bin etc passing a path name which works
for the application, it will break for the helper.
It also requires all binaries use by the application to live in the
same directory.  This would be OK  for some applications, but not for
everything.

It sounds to me like you want a private, inherited, name space, and
Linux provides those via CLONE_NEWNS, however you probably need root
access to make that work, which isn't ideal.

I think you'd have move luck (ab)using an environment variable.
Make
   /proc/self/env_prefix
be a symlink pointing to whatever the "PREFIX" environment variable
stores.
Then you just need a little shell wrapper around the app with
something like
   path=`readlink /proc/$$/fd/255`
   export PREFIX=`dirname $path`
   exec $PREFIX/$APPLICATION

and build the application with
   ./configure --prefix=/proc/self/env_prefix

I'm not saying this is a "nice" solution, but I think it is no worse
than /proc/self/exedir/, and it should be more robust.

NeilBrown

Re: [PATCH] Add a /proc/self/exedir link

[Joshua Hudson]

On 4/3/06, Mike Hearn <mike@plan99.net> wrote:
> Alright, Andrew Morton indicated that he liked this patch but the idea
> needed discussion and mindshare. I asked Con Kolivas if it made sense to
> go in his desktop patchset for people to try: he said he liked it too
> but it's not his area, and that it should be discussed here.
>
> To clarify, I'm proposing this patch for eventual mainline inclusion.
>
> It adds a simple bit of API - a symlink in /proc/pid - which makes it
> easy to build relocatable software:
>
>    ./configure --prefix=/proc/self/exedir/..
>
> This is useful for a variety of purposes:
>
> * Distributing programs that are runnable from CD or USB key (useful for
>    Linux magazine cover disks)
>
> * Binary packages that can be installed anywhere, for instance, to your
>    home directory
>
> * Network admins can more easily place programs on network mounts
>
> I'm sure you can think of others. You can patch software to be
> relocatable today, but it's awkward and error prone. A simple patch can
> allow us to get it "for free" on any UNIX software that uses the
> idiomatic autotools build system.
>
> So .... does anybody have any objections to this? Would you like to see
> it go in? Speak now or forever hold your peace! :)
>
> thanks -mike
Love it. I hope it doesn't get shot down.

[PATCH] Add a /proc/self/exedir link

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Alright, Andrew Morton indicated that he liked this patch but the idea 
needed discussion and mindshare. I asked Con Kolivas if it made sense to 
go in his desktop patchset for people to try: he said he liked it too 
but it's not his area, and that it should be discussed here.

To clarify, I'm proposing this patch for eventual mainline inclusion.

It adds a simple bit of API - a symlink in /proc/pid - which makes it 
easy to build relocatable software:

   ./configure --prefix=/proc/self/exedir/..

This is useful for a variety of purposes:

* Distributing programs that are runnable from CD or USB key (useful for
   Linux magazine cover disks)

* Binary packages that can be installed anywhere, for instance, to your
   home directory

* Network admins can more easily place programs on network mounts

I'm sure you can think of others. You can patch software to be 
relocatable today, but it's awkward and error prone. A simple patch can 
allow us to get it "for free" on any UNIX software that uses the 
idiomatic autotools build system.

So .... does anybody have any objections to this? Would you like to see 
it go in? Speak now or forever hold your peace! :)

thanks -mike

[-- Attachment #2: exedir.patch --]
[-- Type: text/x-patch, Size: 3195 bytes --]

--- fs/proc/base.c~	2006-03-22 21:39:04.000000000 +0000
+++ fs/proc/base.c	2006-03-22 09:42:28.000000000 +0000
@@ -95,6 +95,7 @@
 	PROC_TGID_CWD,
 	PROC_TGID_ROOT,
 	PROC_TGID_EXE,
+	PROC_TGID_EXEDIR,
 	PROC_TGID_FD,
 	PROC_TGID_ENVIRON,
 	PROC_TGID_AUXV,
@@ -135,6 +136,7 @@
 	PROC_TID_CWD,
 	PROC_TID_ROOT,
 	PROC_TID_EXE,
+	PROC_TID_EXEDIR,
 	PROC_TID_FD,
 	PROC_TID_ENVIRON,
 	PROC_TID_AUXV,
@@ -200,6 +202,7 @@
 	E(PROC_TGID_CWD,       "cwd",     S_IFLNK|S_IRWXUGO),
 	E(PROC_TGID_ROOT,      "root",    S_IFLNK|S_IRWXUGO),
 	E(PROC_TGID_EXE,       "exe",     S_IFLNK|S_IRWXUGO),
+	E(PROC_TGID_EXEDIR,    "exedir",  S_IFLNK|S_IRWXUGO),
 	E(PROC_TGID_MOUNTS,    "mounts",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_MMU
 	E(PROC_TGID_SMAPS,     "smaps",   S_IFREG|S_IRUGO),
@@ -242,6 +245,7 @@
 	E(PROC_TID_CWD,        "cwd",     S_IFLNK|S_IRWXUGO),
 	E(PROC_TID_ROOT,       "root",    S_IFLNK|S_IRWXUGO),
 	E(PROC_TID_EXE,        "exe",     S_IFLNK|S_IRWXUGO),
+	E(PROC_TID_EXEDIR,     "exedir",  S_IFLNK|S_IRWXUGO),
 	E(PROC_TID_MOUNTS,     "mounts",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_MMU
 	E(PROC_TID_SMAPS,      "smaps",   S_IFREG|S_IRUGO),
@@ -1656,6 +1660,11 @@
 			inode->i_op = &proc_pid_link_inode_operations;
 			ei->op.proc_get_link = proc_exe_link;
 			break;
+		case PROC_TID_EXEDIR:
+		case PROC_TGID_EXEDIR:
+			inode->i_op = &proc_pid_link_inode_operations;
+			ei->op.proc_get_link = proc_exedir_link;
+			break;
 		case PROC_TID_CWD:
 		case PROC_TGID_CWD:
 			inode->i_op = &proc_pid_link_inode_operations;
--- fs/proc/internal.h~	2006-03-13 23:40:39.000000000 +0000
+++ fs/proc/internal.h	2006-03-22 09:46:08.000000000 +0000
@@ -32,6 +32,7 @@
 
 extern void create_seq_entry(char *name, mode_t mode, struct file_operations *f);
 extern int proc_exe_link(struct inode *, struct dentry **, struct vfsmount **);
+extern int proc_exedir_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt);
 extern int proc_tid_stat(struct task_struct *,  char *);
 extern int proc_tgid_stat(struct task_struct *, char *);
 extern int proc_pid_status(struct task_struct *, char *);
--- fs/proc/task_mmu.c~	2006-03-22 21:43:37.000000000 +0000
+++ fs/proc/task_mmu.c	2006-03-22 10:26:37.000000000 +0000
@@ -101,6 +101,20 @@
 	return result;
 }
 
+int proc_exedir_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt)
+{
+	struct dentry *exe;
+	int result = proc_exe_link(inode, &exe, mnt);
+
+	if (result < 0)
+		return result;
+
+	*dentry = dget_parent(exe);
+	dput(exe);
+
+	return result;
+}
+
 static void pad_len_spaces(struct seq_file *m, int len)
 {
 	len = 25 + sizeof(void*) * 6 - len;
--- fs/proc/task_nommu.c~	2006-03-22 21:45:24.000000000 +0000
+++ fs/proc/task_nommu.c	2006-03-22 10:20:26.000000000 +0000
@@ -137,6 +137,20 @@
 	return result;
 }
 
+int proc_exedir_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt)
+{
+	struct dentry *exe;
+	int result = proc_exe_link(inode, &exe, mnt);
+	
+	if (result < 0)
+		return result;
+
+	*dentry = dget_parent(exe);
+	dput(exe);
+
+       return result;
+}
+
 /*
  * Albert D. Cahalan suggested to fake entries for the traditional
  * sections here.  This might be worth investigating.