Adrian Bunk [EMAIL PROTECTED] writes:
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen [EMAIL PROTECTED] wrote:
so... where do we stand with this? Fundamental, irreconcilable
differences over the use of pathname-based
Miklos Szeredi [EMAIL PROTECTED] writes:
On Apr 25 2007 11:21, Eric W. Biederman wrote:
Why did we want to use fsuid, exactly?
- Because ruid is completely the wrong thing we want mounts owned
by whomever's permissions we are using to perform the mount.
Think nfs. I access some nfs
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
- refine adding nosuid and nodev flags for unprivileged mounts:
o add nosuid, only if mounter doesn't have CAP_SETUID capability
o add nodev, only if mounter doesn't have CAP_MKNOD capability
- allow
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
Miklos Szeredi wrote:
Andrew, please skip this patch, for now.
Serge found a problem with the fsuid approach: setfsuid(nonzero) will
remove filesystem related capabilities. So even if root is
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Are there other permission checks that mount is doing that we
care about.
Not mount itself, but in looking up /share/fa/root/home/fa,
user fa doesn't have the rights to read /share, and by setting
Karel Zak [EMAIL PROTECTED] writes:
On Fri, Apr 20, 2007 at 12:25:32PM +0200, Miklos Szeredi wrote:
The following extra security measures are taken for unprivileged
mounts:
- usermounts are limited by a sysctl tunable
- force nosuid,nodev mount options on the created mount
The
Miklos Szeredi [EMAIL PROTECTED] writes:
Does this mean, that containers will need this? Or that you don't
know yet?
The uid namespace is something we have to handle carefully and we
have not decided on the final design.
What is clear is that all permission checks will need to become
either
Miklos Szeredi [EMAIL PROTECTED] writes:
The MNT_USER flag is not copied on any kind of mount cloning:
namespace creation, binding or propagation.
I half agree, and as an initial approximation this works.
Ultimately we should be at the point that for mount propagation
that we copy the
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be
Andrew Morton [EMAIL PROTECTED] writes:
On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote:
+static bool permit_umount(struct vfsmount *mnt, int flags)
+{
...
+return mnt-mnt_uid == current-uid;
+}
Yes, this seems very wrong. I'd have
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Add ownership information to mounts.
A new mount flag, MS_SETUSER is used to make a mount owned by a user.
If this flag is specified, then the owner will be set to the current
real user id and the mount will be
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be owned by
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Allow clone_mnt() to return errors other than ENOMEM. This will be
used for returning a different error value when the number of user
mounts goes over the limit.
Fix copy_tree() to return EPERM for unbindable
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Allow bind mounts to unprivileged users if the following conditions
are met:
- mountpoint is not a symlink or special file
Why? This sounds like a left over from when we were checking permissions.
-
Andrew Morton [EMAIL PROTECTED] writes:
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote:
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
Use FS_SAFE for fuse fs type, but not for fuseblk.
FUSE was designed from the beginning to be safe for unprivileged
users. This has also been verified in practice over many years. In
addition unprivileged
Jan Engelhardt [EMAIL PROTECTED] writes:
On Apr 21 2007 08:10, Eric W. Biederman wrote:
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged
mounting
Andi Kleen [EMAIL PROTECTED] writes:
Andrew Morton [EMAIL PROTECTED] writes:
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote:
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
This patchset has now been bared to the lowest common denominator
that everybody can agree on. Or at least there weren't any objections
to this proposal.
Andrew, please consider it for -mm.
Thanks,
Miklos Szeredi [EMAIL PROTECTED] writes:
I've tried to make this unprivileged mount thing as simple as
possible, and no simpler. If we can make it even simpler, all the
better.
We are certainly much more complex then the code in plan9 (just
read through it) so I think we have room for
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user hallyn does mount --bind / /home/hallyn/root
2. (...)
Miklos Szeredi [EMAIL PROTECTED] writes:
I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some extent
Miklos Szeredi [EMAIL PROTECTED] writes:
I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some
Miklos Szeredi [EMAIL PROTECTED] writes:
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I think privileges of this sort should propagate. If I read
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I think privileges of this sort should propagate. If I
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Given the existence of shared subtrees allowing/denying this at the mount
namespace level is silly and wrong.
If we need more than just the filesystem permission checks can we
make it a mount flag
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible enough, because
Modify the device class code so that normal manipulations work
in the presence of shadow directories. Some of the shadow directory
support still needs to be implemented in the implementation of the
class but these modifications are sufficient to make that simple.
Signed-off-by: Eric W
Greg KH [EMAIL PROTECTED] writes:
Or you can try it with any of the subsystems that have already been
converted over to use the struct device code, like misc, mem, and many
others. Just look for the symlinks in /sys/class/CLASS_NAME/ instead of
real subdirectories.
So I'd really prefer to
Matthew Wilcox [EMAIL PROTECTED] writes:
On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
What do you mean by problems 5 years down the road? The real issue is that
this 32-bit block count limit affects composite devices like MD RAID and
LVM today, not just individual
LA Walsh [EMAIL PROTECTED] writes:
I vaguely remember a discussion about this a few months back.
If I remember, the reasoning was it would unnecessarily slow
down smaller systems that would never have block devices in
the 4-28T range attached.
With classic 512 byte sectors the top size is
Alexander Viro [EMAIL PROTECTED] writes:
IOW, you can get normal filesystem view (meaning that you have all usual
UNIX toolkit available) for per-fs control stuff. And keep the ability to
do proper locking - it's the same driver that handles the main fs and you
have access to superblock. No
"Jeff V. Merkey" [EMAIL PROTECTED] writes:
Cool. ORACLE is going to **SMOKE** on EXT2 with this change.
Pessimism
Hmm I don't see how ORACLE is going to **SMOKE**.
Last I looked ORACLE would need a query optimizer that always
would find the best possible index and much less overhead to
36 matches
Mail list logo
