lkml.org 
[lkml]   [2005]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: what's next for the linux kernel?
On Wed, 5 Oct 2005, David Leimbach wrote:

[snip quotes]

> It would if the rest of the system really enforced this "privacy". In
> plan 9 /tmp is really a bind to /usr/$user/tmp. And if you launch
> something like "ramfs" [a userland 9P server] it binds a ram disk
> device over /tmp by default unless you tell it otherwise, then you
> have a ram-backed directory only for the current process and its
> children in /tmp.
[...]

> This is useful for pulling things out of the
> encrypted storage like factotum keys [sort of like a keyring for all
> factotum based authentication including 9P mounts and even ssh
> connections that use no ssh-keys]. When your process goes away so
> does the decrypted keyfile, pretty nice.

You'd usurally just create+open a file and erase it without closing it.
The only access to this file is by using the file descriptor (or, off
cause, /proc/pid/fd/num). If the last reference to this file, the running
process, is gone, so is the file.

> Back on topic...
>
> The problem with private namespaces on Linux is that they really
> aren't so much. mount will update /etc/mtab for all to see and even

Userspace problem.-)

> /proc/<pid>/mounts is world readable [though it doesn't give useful
> bind information anyway on linux... just the disk device it appears].

There was some proc privacy patch some time ago. It was argued about
because some sites want peer review on system usage. I lost track
if it was included.

> I think private namespaces could actually be made more-so but the rest
> of the system has to cooperate and I doubt that I have the energy to
> do the evangelism and requisite proofs of concept for Linux. It's far
> easier for me to just use Plan 9 and Inferno instead of trying to
> assimilate Linux, even though I think I'd prefer Linux if it were more
> like the former two.

The plan is:

1) make namespaces joinable
2) ???
3) profit

No, that's wrong. The plan is (should be?):

1) make namespaces joinable in a sane way
2) wait for the shared subtree patch
3) make pam join the per-user-namespace
4) make pam automount tmpfs on the private /tmp

--
Top 100 things you don't want the sysadmin to say:
44. System coming down in 0 min....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2005-10-05 18:28    [from the cache]
©2003-2011 Jasper Spaans