* [PATCH] Add a /proc/self/exedir link
@ 2006-04-03 23:01 Mike Hearn
2006-04-03 23:26 ` Joshua Hudson
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Mike Hearn @ 2006-04-03 23:01 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm
[-- 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-03 23:01 [PATCH] Add a /proc/self/exedir link Mike Hearn
@ 2006-04-03 23:26 ` Joshua Hudson
2006-04-03 23:30 ` Neil Brown
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Joshua Hudson @ 2006-04-03 23:26 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-03 23:01 [PATCH] Add a /proc/self/exedir link 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-05 20:39 ` Eric W. Biederman
3 siblings, 0 replies; 18+ messages in thread
From: Neil Brown @ 2006-04-03 23:30 UTC (permalink / raw)
To: Mike Hearn; +Cc: linux-kernel, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-03 23:01 [PATCH] Add a /proc/self/exedir link 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
3 siblings, 1 reply; 18+ messages in thread
From: Jan Engelhardt @ 2006-04-04 15:54 UTC (permalink / raw)
To: Mike Hearn; +Cc: linux-kernel, akpm
> ./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
--
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-04 15:54 ` Jan Engelhardt
@ 2006-04-04 21:24 ` Nix
0 siblings, 0 replies; 18+ messages in thread
From: Nix @ 2006-04-04 21:24 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Mike Hearn, linux-kernel, akpm
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.'
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-03 23:01 [PATCH] Add a /proc/self/exedir link Mike Hearn
` (2 preceding siblings ...)
2006-04-04 15:54 ` Jan Engelhardt
@ 2006-04-05 20:39 ` Eric W. Biederman
2006-04-05 21:52 ` Mike Hearn
3 siblings, 1 reply; 18+ messages in thread
From: Eric W. Biederman @ 2006-04-05 20:39 UTC (permalink / raw)
To: Mike Hearn; +Cc: linux-kernel, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-05 20:39 ` Eric W. Biederman
@ 2006-04-05 21:52 ` Mike Hearn
2006-04-06 23:33 ` Tony Luck
0 siblings, 1 reply; 18+ messages in thread
From: Mike Hearn @ 2006-04-05 21:52 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel, akpm
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-05 21:52 ` Mike Hearn
@ 2006-04-06 23:33 ` Tony Luck
2006-04-07 7:52 ` Neil Brown
0 siblings, 1 reply; 18+ messages in thread
From: Tony Luck @ 2006-04-06 23:33 UTC (permalink / raw)
To: Mike Hearn; +Cc: Eric W. Biederman, linux-kernel, akpm
> > 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-06 23:33 ` Tony Luck
@ 2006-04-07 7:52 ` Neil Brown
2006-04-07 9:15 ` Andreas Schwab
0 siblings, 1 reply; 18+ messages in thread
From: Neil Brown @ 2006-04-07 7:52 UTC (permalink / raw)
To: Tony Luck; +Cc: Mike Hearn, Eric W. Biederman, linux-kernel, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
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
0 siblings, 2 replies; 18+ messages in thread
From: Andreas Schwab @ 2006-04-07 9:15 UTC (permalink / raw)
To: Neil Brown; +Cc: Tony Luck, Mike Hearn, Eric W. Biederman, linux-kernel, akpm
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."
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-07 9:15 ` Andreas Schwab
@ 2006-04-07 19:10 ` Eric W. Biederman
2006-04-08 8:26 ` Jan Engelhardt
1 sibling, 0 replies; 18+ messages in thread
From: Eric W. Biederman @ 2006-04-07 19:10 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Neil Brown, Tony Luck, Mike Hearn, linux-kernel, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link
2006-04-07 9:15 ` Andreas Schwab
2006-04-07 19:10 ` Eric W. Biederman
@ 2006-04-08 8:26 ` Jan Engelhardt
1 sibling, 0 replies; 18+ messages in thread
From: Jan Engelhardt @ 2006-04-08 8:26 UTC (permalink / raw)
To: Andreas Schwab
Cc: Neil Brown, Tony Luck, Mike Hearn, Eric W. Biederman, linux-kernel, akpm
>>> 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
--
^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <5XGlt-GY-23@gated-at.bofh.it>]
end of thread, other threads:[~2006-04-08 8:26 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-03 23:01 [PATCH] Add a /proc/self/exedir link 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
[not found] <5XGlt-GY-23@gated-at.bofh.it>
[not found] ` <5XGOz-1eP-35@gated-at.bofh.it>
2006-04-06 11:39 ` Bodo Eggert
2006-04-06 13:21 ` Mike Hearn
2006-04-06 17:02 ` Bodo Eggert
2006-04-06 19:36 ` Mike Hearn
2006-04-07 18:40 ` Eric W. Biederman
2006-04-07 19:22 ` Mike Hearn
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).