From: Mike Hearn <mike@plan99.net>
To: 7eggert@gmx.de
Cc: Neil Brown <neilb@suse.de>, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] Add a /proc/self/exedir link
Date: Thu, 06 Apr 2006 14:21:37 +0100 [thread overview]
Message-ID: <443515E1.1000600@plan99.net> (raw)
In-Reply-To: <E1FRSqP-0000g3-9i@be1.lrz>
> 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
next prev parent reply other threads:[~2006-04-06 13:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5XGlt-GY-23@gated-at.bofh.it>
[not found] ` <5XGOz-1eP-35@gated-at.bofh.it>
2006-04-06 11:39 ` [PATCH] Add a /proc/self/exedir link Bodo Eggert
2006-04-06 13:21 ` Mike Hearn [this message]
2006-04-06 17:02 ` Bodo Eggert
2006-04-06 19:36 ` Mike Hearn
2006-04-07 18:40 ` Eric W. Biederman
[not found] ` <bda6d13a0604071201o36496a55o2eae6a65153a06c3@mail.gmail.com>
2006-04-07 19:01 ` Fwd: " Joshua Hudson
2006-04-07 19:17 ` John Stoffel
2006-04-07 19:22 ` Mike Hearn
2006-04-03 23:01 Mike Hearn
2006-04-03 23:26 ` Joshua Hudson
2006-04-03 23:30 ` Neil Brown
2006-04-04 15:54 ` Jan Engelhardt
2006-04-04 21:24 ` Nix
2006-04-05 20:39 ` Eric W. Biederman
2006-04-05 21:52 ` Mike Hearn
2006-04-06 23:33 ` Tony Luck
2006-04-07 7:52 ` Neil Brown
2006-04-07 9:15 ` Andreas Schwab
2006-04-07 19:10 ` Eric W. Biederman
2006-04-08 8:26 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=443515E1.1000600@plan99.net \
--to=mike@plan99.net \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).