On Wed, Apr 20, 2005 at 18:09:21 +0100, Al Viro wrote:
On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
On Thu, Apr 21, 2005 at 09:33:20AM +0200, Jan Hudec wrote:
I think I can. And I think I can modify the proposal to something a bit
more sane.
The problem is: The mount should be accessible only by processes started
by the authorized user, but not by other user, including root, who is
On Wed, Apr 20, 2005 at 05:23:10PM -0700, Bryan Henderson wrote:
That assumes that everyone has the same stuff in the same places. I.e.
that there is a universal tree with different subset hidden from
different
processes. But that is obviously a wrong approach - e.g. it loses
ability
to
OK, I overlooked the problem of having to add commands to the shell and
everything else. While there's plenty of precedent for this style
(current directory, ulimits, umask), I wouldn't like to extend it, even to
adding a command to Bash. But it could follow the 'nice' and 'renice'
On Thu, Apr 21, 2005 at 09:09:01 +0100, Christoph Hellwig wrote:
On Thu, Apr 21, 2005 at 09:33:20AM +0200, Jan Hudec wrote:
I think I can. And I think I can modify the proposal to something a bit
more sane.
The problem is: The mount should be accessible only by processes started
by
It would still not work for ftp-server style programs,
True. Users might want the mounts to show up to an ftp or not, and this
handles only not.
If used in conjuction with CLONE_NEWNS it would have all the needed
flexibility.
I don't see how. What if my policy is that processes with a
Jan Hudec wrote:
By the way, IIRC so far the root can access all kernel memory too via
/dev/kmem. So the limiting of root's rights would have to be limited
a bit more yet.
On some hardened systems, root is not allowed access to /dev/kmem.
-- Jamie
-
To unsubscribe from this list: send the
On Thu, Apr 21, 2005 at 19:44:56 +0100, Jamie Lokier wrote:
Jan Hudec wrote:
By the way, IIRC so far the root can access all kernel memory too via
/dev/kmem. So the limiting of root's rights would have to be limited
a bit more yet.
On some hardened systems, root is not allowed access to
On Wed, 2005-04-20 at 17:42, Bryan Henderson wrote:
Well I am not aware of issues that can arise if a user is allowed to
change to some namespace for which it has permission to switch.
I think I misunderstood your proposal.
A user 'ram' creates a namespace 'n1' with a device node /dev/n1
Jan Hudec wrote:
On Thu, Apr 21, 2005 at 19:44:56 +0100, Jamie Lokier wrote:
Jan Hudec wrote:
By the way, IIRC so far the root can access all kernel memory too via
/dev/kmem. So the limiting of root's rights would have to be limited
a bit more yet.
On some hardened systems, root
Al Viro wrote:
Most of the code is already there - do_fork() has to do such stuff anyway.
So how about adding sys_unshare(flags) that would do that job? Flags would
correspond to those of clone(2), except that all these guys would be
what do we unshare instead of what do we leave shared.
On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
For FUSE, what's needed is that a user can mount something, and the
mounted fs is visible only to that user, but it's visible to _all_ of
the user's processes.
So get that namespace as soon as you log in.
We think namespaces are
Al Viro wrote:
On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
For FUSE, what's needed is that a user can mount something, and the
mounted fs is visible only to that user, but it's visible to _all_ of
the user's processes.
So get that namespace as soon as you log in.
Yes.
On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that. chroot-jail style
virtual server environments require that too.
But that shouldn't be the only option -
On Wed, Apr 20, 2005 at 10:45:58 +0100, Jamie Lokier wrote:
Al Viro wrote:
Most of the code is already there - do_fork() has to do such stuff anyway.
So how about adding sys_unshare(flags) that would do that job? Flags would
correspond to those of clone(2), except that all these guys would
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
a) ability to create a private namespace without forking anything - sure,
that would be useful. However, that's not something I
On 4/20/05, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
Yeah, that was really slimy, just wanted something that would be more
accessible to end users without having to affect changes to lots of
applications. A somewhat less slimy method would be to expose
something in /proc, but I suppose
On Wed, 2005-04-20 at 05:39, Al Viro wrote:
On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that. chroot-jail style
virtual server environments require that too.
On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
multiple login sessions.
3) Being able to switch some
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
multiple login sessions.
3) Being able to switch some processes to some other
VFS-mount
On 4/20/05, Al Viro [EMAIL PROTECTED] wrote:
Excuse me, but could somebody give coherent rationale for such requirements?
_Especially_ for joining existing group by completely unrelated process -
something we don't do for any other component of process.
On Wed, Apr 20, 2005 at 09:51:26AM
On 4/20/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
The user expects to have the see the same files in all sessions,
whether those be local logins, remote logins, ftp/scp/etc sessions.
A single global namespace makes perfect sense here. Why do people
want private namespaces?
I disagree
But that shouldn't be the only option - because it would be horrible
to use. If I login on multiple terminals, I normally want to mount
filesystems in /home/jamie/mnt on one terminal, and use them on
another.
And when you log in on several terminals you usually want same $PATH.
You don't do
On Wed, 2005-04-20 at 10:09, Al Viro wrote:
On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
multiple
(Please don't post separately to different recipients, that makes
replying quite awkward. Always reply to all, it's the Right Thing)
I disagree with this, I think there are plenty of situations where I
may want to have several different namespaces for several different
sessions. Once you
How about making namespace's as first class objects with some associated
name or device in the device tree having owner/permissions etc. any
process which forks off a namespace shall create the
device node for the namespace. If some other process wants to use
the same namespace, it can do so by
For the issues being discussed here, I don't think that's materially
different from what we started with; it has the same issue concerning
whether a user should be allowed to change his namespace and whether a
process' namespace should change automatically when another process does
On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
Al Viro is right to point out that environment variables are not
shared. But he forgets that _files_ are shared.
So they are. ~/.profile, for instance ;-)
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
On Wed, Apr 20, 2005 at 07:53:04PM +0200, Miklos Szeredi wrote:
The user expects to have the see the same files in all sessions,
whether those be local logins, remote logins, ftp/scp/etc sessions.
Umm... You know, I would be *very* unhappy if I found that some process
on parcelfarce was able
On Wed, 2005-04-20 at 11:57, Bryan Henderson wrote:
How about making namespace's as first class objects with some associated
name or device in the device tree having owner/permissions etc. any
process which forks off a namespace shall create the
device node for the namespace. If some other
Ram wrote:
What we really want is a mount point that propagates across all the
processes owned by one user, but is not there for other users.
This is almost certainly bogus. Same user can easily want several
different environments set on the same box.
Yes of course.
The problem is the
Jan Hudec wrote:
For FUSE, what's needed is that a user can mount something, and the
mounted fs is visible only to that user, but it's visible to _all_ of
the user's processes.
Including root's su to that user...
Keeping information in a process group is the *only* way to actually
lock
Al Viro wrote:
On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
Al Viro is right to point out that environment variables are not
shared. But he forgets that _files_ are shared.
So they are. ~/.profile, for instance ;-)
And ~/.cvspass. Mysteriously, when I add something to
Al Viro wrote:
If I'm remotely logged into server X from Y, and want to use scp to
copy some file from X to Y or vica versa, I will want my private
mounts to be visible from the scp.
Do you? Really? OK, so I've got ~/bin/ and ~/bin/arch/ in my path on
my boxen. The latter has
Well I am not aware of issues that can arise if a user is allowed to
change to some namespace for which it has permission to switch.
I think I misunderstood your proposal.
A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having
permission 700 owned by the user 'ram'. The user
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount system calls -- adding a flag which created a
new namespace for the resulting
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
*UGH*
So what happens to those who happen to
On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation
39 matches
Mail list logo
