linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Mike Hearn <mike@plan99.net>
Cc: Bodo Eggert <7eggert@gmx.de>, Neil Brown <neilb@suse.de>,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] Add a /proc/self/exedir link
Date: Fri, 07 Apr 2006 12:40:34 -0600	[thread overview]
Message-ID: <m164llns9p.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <44356DAA.90209@plan99.net> (Mike Hearn's message of "Thu, 06 Apr 2006 20:36:10 +0100")

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

  reply	other threads:[~2006-04-07 18:42 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
2006-04-06 17:02       ` Bodo Eggert
2006-04-06 19:36         ` Mike Hearn
2006-04-07 18:40           ` Eric W. Biederman [this message]
     [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=m164llns9p.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=7eggert@gmx.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike@plan99.net \
    --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).