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 a
user is first needed
[akpm]
- don't use
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
mounts require the parent mount to be owned by the
From: Miklos Szeredi [EMAIL PROTECTED]
This patchset adds support for keeping mount ownership information in the
kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
The mount owner has the following privileges:
- unmount the owned mount
- create a submount under the
From: Miklos Szeredi [EMAIL PROTECTED]
Allow bind mounts to unprivileged users if the following conditions are met:
- mountpoint is not a symlink
- parent mount is owned by the user
- the number of user mounts is below the maximum
Unprivileged mounts imply MS_SETUSER, and will also have
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 mounts.
Don't propagate further from
From: Miklos Szeredi [EMAIL PROTECTED]
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated. Also if the parent has the
nosuid flag, set this flag for the child as well.
This makes sense for example, when propagation is set up from the
From: Miklos Szeredi [EMAIL PROTECTED]
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 in
mind, a thorough audit is needed before setting this
After much sitting in -mm, Andrew dropped this patchset due to
conflicts with other stuff. It would be nice, if it could be reviewed
in time for 2.6.26 (2.6.25 is closed as far as I understand).
v5 - v6:
- update to latest -mm
- preliminary util-linux-ng support (will post right after this
Hello.
Indan Zupancic wrote:
I want to use this filesystem in case where a process with root privilege
was
hijacked but the behavior of the hijacked process is still restricted by
MAC.
1) If the behaviour can be controlled, why can't the process be
disallowed to change anything
Hello.
[EMAIL PROTECTED] wrote:
Ouch. The .c files should generally be built into their own .o files and
then the Makefile should do something like
obj-$(CONFIG_SYAORAN) += syaoran.o
unless there's *really* good reasons for including .c files (such as an
otherwise-messy
Mike Frysinger, le Tue 08 Jan 2008 10:31:04 -0500, a écrit :
with all the non-linux changes that have gone in, does there need to be
header
checks here and then have mount.c key off of them ? i'm thinking so ...
Sure!
Samuel
-
To unsubscribe from this list: send the line unsubscribe
On Tuesday 08 January 2008, Miklos Szeredi wrote:
--- util-linux-ng.orig/configure.ac 2008-01-07 21:40:22.0 +0100
+++ util-linux-ng/configure.ac2008-01-07 21:40:50.0 +0100
@@ -91,6 +92,11 @@ fi
UTIL_CHECK_LIB(util, openpty)
UTIL_CHECK_LIB(termcap, tgetnum)
Hi Tetsuo,
I think you focus too much on your way of enforcing filename/attributes
pairs. The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
This because expected combinations are known beforehand. And once
those
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
plain text document attachment
(unprivileged-mounts-account-user-mounts.patch)
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
...
+int nr_user_mounts;
+int
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if (nr_user_mounts = max_user_mounts !capable(CAP_SYS_ADMIN))
+ err = -EPERM;
+ else
+
@@ -510,10 +533,16 @@ static struct vfsmount *clone_mnt(struct
int flag)
{
struct super_block *sb = old-mnt_sb;
- struct vfsmount *mnt = alloc_vfsmnt(old-mnt_devname);
+ struct vfsmount *mnt;
+ if (flag
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if (nr_user_mounts = max_user_mounts !capable(CAP_SYS_ADMIN))
+ err = -EPERM;
+ else
+
On Tue, 2008-01-08 at 20:08 +0100, Miklos Szeredi wrote:
The logic behind EPERM, is that this failure is only for unprivileged
callers. ENOMEM is too specifically about OOM. It could be changed
to ENOSPC, ENFILE, EMFILE, or it could remain EPERM. What do others
think?
Since you're
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
plain text document attachment
(unprivileged-mounts-account-user-mounts.patch)
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
...
+int nr_user_mounts;
On Tue, 8 Jan 2008, Miklos Szeredi wrote:
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if (nr_user_mounts = max_user_mounts !capable(CAP_SYS_ADMIN))
+
On Tue 2008-01-08 12:35:03, Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This patchset adds support for keeping mount ownership information in the
kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
The mount owner has the following privileges:
-
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
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
Hi.
Miklos Szeredi wrote:
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
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
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hello.
[EMAIL PROTECTED] wrote:
Good summary - probably should add that to the patch, drop it into
Documentation/syaoran-config.txt or similar...
I see.
Modification while reading *is* an issue, but can probably be worked around
with some clever locking. The race condition I was thinking of
On Jan 8, 2008 8:40 PM, Al Boldi [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Has there been some thought about an incremental fsck?
You know, somehow fencing a sub-dir to do an online fsck?
Search for chunkfs
Sure, and there is TileFS too.
But
26 matches
Mail list logo
