On Sat, Apr 16, 2005 at 10:06:52AM +, Timothy R. Chavez wrote:
Hello,
The audit subsystem is currently incapable of auditing a file system object
based on its location and name. This is critical for auditing well-defined
and security-relevant locations such as /etc/shadow, where the
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 4/19/05, Ram [EMAIL PROTECTED] wrote:
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
Is this sufficient to cover any exposure? What's the correct solution
for the shared sub-trees RFC? Should there be something similar for
user mounts/binds?
A new namespace in a shared
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 Mon, 11 Apr 2005, Jeff Moyer wrote:
== Regarding [PATCH 1/3] autofs4 - expiring filesystem from under process;
[EMAIL PROTECTED] adds:
Could also please explain how the following is handled:
expire process runs and issues AUTOFS_EXPIRE_MULTI, which sets
AUTOFS_INF_EXPIRING in flags.
On Tue, 2005-04-19 at 13:41, Martin Jambor wrote:
1) Currently none of the generic helper routines can handle this.
We need to add support to do these, but still somehow make the
routines generic enough for every ones use.
I'm quite happy about most of them. I can't see how we could
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, 2005-04-20 at 05:47, Eric Van Hensbergen wrote:
On 4/19/05, Ram [EMAIL PROTECTED] wrote:
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
Is this sufficient to cover any exposure? What's the correct solution
for the shared sub-trees RFC? Should there be something
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
In essense, I was
thinking of splitting up the concepts of 1) accessing the filesystem on
the HDD/device and 2) setting up a namespace for accessing the files
into two separate concepts
I've been crusading for years to get people to understand that a classic
Unix mount is composed of these two
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
On 4/20/05, Bryan Henderson [EMAIL PROTECTED] wrote:
In essense, I was
thinking of splitting up the concepts of 1) accessing the filesystem on
the HDD/device and 2) setting up a namespace for accessing the files
into two separate concepts
I've been crusading for years to get people to
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
Mike Waychison [EMAIL PROTECTED] wrote:
Consider the following pseudo example:
main():
chdir(/);
fd = open(., O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir(..);
if main is run within a chroot where it's / is on the same vfsmount as
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
== Regarding Re: [PATCH 1/3] autofs4 - expiring filesystem from under process;
[EMAIL PROTECTED] adds:
raven On Mon, 11 Apr 2005, Jeff Moyer wrote:
== Regarding [PATCH 1/3] autofs4 - expiring filesystem from under
process; [EMAIL PROTECTED] adds:
Could also please explain how the following
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
34 matches
Mail list logo