).
With the attached patch, this passes all your revoke tests on s390,
as well as ltp runalltests.sh.
thanks,
-serge
From: Serge E. Hallyn [EMAIL PROTECTED]
Subject: [PATCH] revoke: do s390 syscalls
revoke: do s390 syscalls
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
(cherry picked from
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
One thing that is missing from this series is the ability to restrict
user mounts to private namespaces. The reason is that private
namespaces have still not gained the momentum and support needed for
painless user experience. So
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
One thing that is missing from this series is the ability to restrict
user mounts to private namespaces. The reason is that private
namespaces have still not gained the momentum and support needed for
painless user experience. So such a
Quoting 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.
Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
It would be nice in general if we could avoid any sort of checks for
(mnt-mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible,
but, taking the two listed examples:
[snip]
It's probably worthwile going after these problematic cases,
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Not objecting to prctl(), but two other options would be
1. add a CLONE_NEW_NS_USERMNT flag - kind of ugly, but that is
the time at which the ns is created, so in that sense it
makes sense.
Yes, I thought about this, but
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 user mounts can't be enabled for
the initial
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move
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 settable with mount and remount that allows
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a bunch of mounts
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
-serge
unprivileged mounts will
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser more clear than usermnt? What is allowed to the
I think so, yes. One makes it clear that we're
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
I'm a bit lost about what is currently done and who advocates for what.
It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
propagated. In the /share rbind+chroot example, I assume the admin
would start by doing
mount
Quoting Bharata B Rao ([EMAIL PROTECTED]):
From: Jan Blunck [EMAIL PROTECTED]
Subject: Introduce union stack.
Adds union stack infrastructure to the dentry structure and provides
locking routines to walk the union stack.
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
Signed-off-by: Bharata
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
v3 - v4:
- simplify
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 trying to
set the user=UID flag on a mount,
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Right, I figure if the normal action is to always do
mnt-user = current-fsuid, then for the special case we
pass a uid in someplace. Of course... do we not have a
place to do that? Would it be a no-no to use 'data' for
a non-fs-specific arg?
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Right, I figure if the normal action is to always do
mnt-user = current-fsuid, then for the special case we
pass a uid in someplace. Of course... do we not have a
place to do that? Would it
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
So then as far as you're concerned, the patches which were in -mm will
remain unchanged?
Basically yes. I've merged the update patch, which was not yet added
to -mm, did some cosmetic code changes, and updated the patch headers.
There's one
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
So then as far as you're concerned, the patches which were in -mm will
remain unchanged?
Basically yes. I've merged the update patch, which was not yet added
to -mm, did some cosmetic code
Quoting Andreas Dilger ([EMAIL PROTECTED]):
On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote:
As the capability set changes and distributions start tagging
binaries with capabilities, we would like for running an older
kernel to not necessarily make those binaries unusable.
(0
Quoting Suparna Bhattacharya ([EMAIL PROTECTED]):
On Thu, May 10, 2007 at 01:01:27PM -0700, Andreas Dilger wrote:
On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote:
Quoting Andreas Dilger ([EMAIL PROTECTED]):
One of the important use cases I can see today is the ability to
split
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
On May 16 2007 10:38, Bharata B Rao wrote:
+lookup_union:
+ do {
+ struct vfsmount *mnt = find_mnt(topmost);
+ UM_DEBUG_DCACHE(name=\%s\, inode=%p, device=%s\n,
+ topmost-d_name.name,
Quoting Suparna Bhattacharya ([EMAIL PROTECTED]):
On Mon, May 14, 2007 at 08:00:11PM +, Pavel Machek wrote:
Hi!
Serge E. Hallyn [EMAIL PROTECTED] wrote:
Following are two patches which have been sitting for some time in -mm.
Where some time == nearly six months
Quoting Paul Dickson ([EMAIL PROTECTED]):
On Mon, 14 May 2007 13:23:06 -0700, Badari Pulavarty wrote:
+ while (fs) {
+ locked = union_trylock(fs-root);
+ if (!locked)
+ goto loop1;
+ locked = union_trylock(fs-altroot);
+ if
Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote:
Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
On Wednesday 06
Quoting Karl MacMillan ([EMAIL PROTECTED]):
On Tue, 2007-06-12 at 10:34 -0500, Serge E. Hallyn wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
[...]
If we added support for named type transitions to SELinux, as proposed
earlier by Kyle Moffett during this discussion, wouldn't
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
Al Viro wrote:
On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):
/dev/md6 /export ext3 rw,data=ordered 0 0
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Add a new filesystem flag, that results in the VFS not checking if the
current process has enough privileges to do an mknod().
This is needed on filesystems, where an unprivileged user may be able
to
Quoting James Morris ([EMAIL PROTECTED]):
On Mon, 22 Oct 2007, David P. Quigley wrote:
Originally vfs_getxattr would pull the security xattr variable using
the inode getxattr handle and then proceed to clobber it with a subsequent
call
to the LSM. This patch reorders the two operations
Quoting David P. Quigley ([EMAIL PROTECTED]):
This patch modifies the interface to inode_getsecurity to have the
function return a buffer containing the security blob and its length via
parameters instead of relying on the calling function to give it an
appropriately sized buffer.
Quoting David P. Quigley ([EMAIL PROTECTED]):
On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
This patch modifies the interface to inode_getsecurity to have the
function return a buffer containing the security blob and its length
Quoting David P. Quigley ([EMAIL PROTECTED]):
On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
static int task_alloc_security(struct task_struct *task)
@@ -2423,14 +2397,22 @@ static const char
*selinux_inode_xattr_getsuffix(void
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
static int
Quoting David P. Quigley ([EMAIL PROTECTED]):
On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
Quoting David P. Quigley ([EMAIL PROTECTED]):
static int
Quoting David P. Quigley ([EMAIL PROTECTED]):
This patch modifies the interface to inode_getsecurity to have the function
return a buffer containing the security blob and its length via parameters
instead of relying on the calling function to give it an appropriately sized
buffer. Security
Quoting David P. Quigley ([EMAIL PROTECTED]):
Originally vfs_getxattr would pull the security xattr variable using
the inode getxattr handle and then proceed to clobber it with a subsequent
call
to the LSM. This patch reorders the two operations such that when the xattr
requested is in the
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
Hello!
I am working on pid namespaces vs locks interaction and want to evaluate the
idea.
fcntl(F_GETLK,..) can return pid of process for not current pid namespace (if
process is belonged to the several namespaces). It is true also for pids
in
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
On 6 December 2007 17:53:40 Serge E. Hallyn wrote:
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
Hello!
I am working on pid namespaces vs locks interaction and want to evaluate
the idea.
fcntl(F_GETLK,..) can return pid of process
Quoting J. Bruce Fields ([EMAIL PROTECTED]):
On Thu, Dec 06, 2007 at 03:57:29PM +0300, Vitaliy Gusev wrote:
I am working on pid namespaces vs locks interaction and want to evaluate
the
idea.
fcntl(F_GETLK,..) can return pid of process for not current pid namespace
(if
process is
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
Hello
On 6 December 2007 18:51:30 Serge E. Hallyn wrote:
fl_pid is used by nfs, fuse and gfs2. For instance nfs keeps in fl_pid
some unique id to identify locking process between hosts - it is not a
process pid.
Ok, but so the struct
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
On 12 December 2007 20:31:15 Serge E. Hallyn wrote:
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
Hello
On 6 December 2007 18:51:30 Serge E. Hallyn wrote:
fl_pid is used by nfs, fuse and gfs2. For instance nfs keeps in
fl_pid some
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
On 12 December 2007 21:42:25 Serge E. Hallyn wrote:
Ok sorry - by letting this thread sit a few days I lost track of where
we were.
I see now, so you're saying fl_pid for nfs is not in fact a task pid.
It's a magically derived unique id
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
A brief description about SYAORAN:
SYAORAN stands for Simple Yet All-important Object Realizing Abiding
Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
/dev needs to be writable, but this means that files on /dev might be
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2).
Sure but that doesn't
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Miklos'
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse
Quoting Oren Laadan ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
Hi Serge,
(Thanks for looking at this. I appreciate the review!)
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
struct vfsmount *mnt = nd-mnt;
- struct dentry *dentry = __d_lookup(nd-dentry, name);
+ struct dentry *dentry;
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
Hi,
On Wed, 19 Dec 2007, Serge E. Hallyn wrote:
I assume you mean S_REVOKE_LOCK and not -i_mutex, right?
No I did mean the i_mutex since you take the i_mutex when you set
S_REVOKE_LOCK. So between that and the comment above do_lookup
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
A brief description about SYAORAN:
SYAORAN stands for Simple Yet All-important Object Realizing Abiding
Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
I apologize if I'm commiting a faux pas by asking this, but any chance
of
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
fcntl(F_GETLK,..) can return pid of process for not current pid namespace (if
process is belonged to the several namespaces). It is true also for pids
in /proc/locks. So correct behavior is saving pointer to the struct pid of
the process lock
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Thank you for attending discussion for previous posting
(starting from http://lkml.org/lkml/2007/12/16/23 ).
The previous posting was for feasibility test to know
whether this kind of trivial filesystem is acceptable for mainline.
Now,
Quoting Indan Zupancic ([EMAIL PROTECTED]):
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
So that you miss alternatives and don't see the bigger picture.
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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.
What about nodev?
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Add a new mount flag nomnt, which denies submounts for the owner.
This would be useful, if we want to support traditional /etc/fstab
based user mounts.
In this case mount(8) would still have to be
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Sounds like a sysctl to enable FS_SAFE for fuse will make this patch
acceptable to everyone?
I think the most generic approach, is to be able to set safeness for
any fs type, not just fuse (Karel's suggestion).
E.g:
echo 1
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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,
Quoting 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.
What about nodev?
Hmm, I think
Quoting Kentaro Takeda ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
I must say I personally prefer the apparmor approach.
No problem.
But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on.
TOMOYO can use AppArmor's patch
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Don't require the user_id= and group_id= options for unprivileged mounts,
but if they are present, verify them for sanity.
Disallow the allow_other option for unprivileged mounts.
FUSE was designed from
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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.
If the parent has the nosuid flag, set this flag for the child as
well. This is needed for
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
Thanks, Miklos, good explanations in the docs.
Acked-by: Serge Hallyn [EMAIL PROTECTED]
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
+ t-table[0].mode = 0644;
Yikes, this could be a problem for containers, as it's simply tied to
uid 0, whereas tying it to a capability would let us solve it with
capability bounds.
This might mean more urgency to get user namespaces
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Maybe sysctls just need to check capabilities, instead of uids. I
think that would make a lot of sense anyway.
Would it be as simple as tagging the inodes with capability sets? One
set for writing, or one each for reading and writing?
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Maybe sysctls just need to check capabilities, instead of uids. I
think that would make a lot of sense anyway.
Would it be as simple as tagging the inodes with capability sets? One
set for writing, or one each for reading and
Quoting David Howells ([EMAIL PROTECTED]):
These patches add local caching for network filesystems such as NFS.
The patches can roughly be broken down into a number of sets:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
Three
86 matches
Mail list logo
