Re: [PATCH] per-process securebits

oticed the following patch is needed on top of yours. -serge >From feac61b47be8375e25b0f6ee876cf096c8b1b9cc Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 14:13:29 + Subject: [PATCH 1/1] per-process securebits: security_task_prctl takes a long

Re: permission denied while load kernel module using modprobe

r-xr-x > Which permission is wrong here ? > > Thanks a lot ! > > Claude Just a few possibilities, 1. could you do 'id -Z' and 'ls -lZ /lib/modules/2.6.23.8-34.fc7/net/' to see if selinux is involved? 2. most commonly on my own laptop i've seen this happe

Re: Question about filesystem capability support

t figure out which of them is the "definitive" one > -- pointers?) This is a good one: http://www.friedhoff.org/fscaps.html thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo i

Re: if (2.6.24.1 && capset && bind9) bug()

Quoting Nick 'Zaf' Clifford ([EMAIL PROTECTED]): > Please CC me on any/all replies > > After trying to upgrade to deal with the most recent security issue, I Judging by the 2.6.24.2 changelog I don't think the 2.6.24.1 kernel you grabbed has the fix you're looking for... > have encountered what

Re: Improve init/Kconfig help descriptions [PATCH 6/9]

Quoting Nick Andrew ([EMAIL PROTECTED]): > On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: > > On Feb 19, 2008 7:12 AM, Nick Andrew <[EMAIL PROTECTED]> wrote: > > > config CGROUPS > > > [...] > > > + When enabled, a new filesystem type "cgroup" is available > > > + and

Re: [PATCH 2.6.25-rc2 3/9] config: Improve init/Kconfig help descriptions - namespaces

namespace > + corresponding to the container, and can only see or > + affect processes in the same PID namespace. Hi Nick, thanks for all this work. Perhaps it would be better to have a Documentation/Namespaces/PID file describing these semantics, and have the description read som

Re: where is the capset kernel module?

isn't telling you you need a kernel module, but that you are using an old libcap. It isn't a real problem right now if you're not using the SMACK LSM, but to get rid of the message upgrade your libcap from http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/libcap-2.05.t

Re: [PATCH 1/2] New system call, unshare

mespace. At least not that I could figure out. Seemed possible that cloning, exiting the original thread, and returning from the new thread could work, but it didn't seem to work when I tried it. thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel&

Re: [patch 5/12] lsm stacking v0.2: actual stacker module

Quoting Tony Jones ([EMAIL PROTECTED]): > Hey Serge, > > I don't think your symbol_get() is doing what you think it is ;-) Hmm, I wonder whether something changed. It shouldn't be possible to rmmod module b if module a has done a symbol_get on it... This may mean more string

Re: [PATCH 3/3] Use conditional

t; with one stone. Yes, sorry, I never got around to the replace-dummy-with-capability patch. There wasn't a single cry when Chris asked for anyone who'd care about dummy being removed, so I do plan on switching that. thanks, -serge - To unsubscribe from this list: send the line "

Re: [PATCH 3/3] Use conditional

f my patches? Or should I start ... ? I think your patches to make capability the default are the best place to start. Doing the same under stacker will be trivial, and I'll do that in the next set I send out. thanks, -serge - To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH] securityfs

ecurity relevant stuff under one place has been something we've wanted to do for awhile :) Thanks, Greg! All my good machines are down right now, so compiling is slow, but I'm attempting to convert seclvl to use securityfs. So far the resulting code is quite nice. I'll hopefull

Re: [PATCH] securityfs

s? Tested without a hitch. In addition, the attached patch converts seclvl to use the securityfs. Also tested without any problems. (Only meant as proof of concept: Mike, you'll probably want to at least add the passwd_read_file function back in, I assume?) thanks, -serge -- seclvl.c |

Re: [patch 5/12] lsm stacking v0.2: actual stacker module

ly a new LSM hook seems the cleanest solution. Or, I could ramp up the locking and permit module deletion, probably at a bit of performance cost. Or I could just count on modules doing a symbol_get on themselves? thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-ker

Re: [patch 5/12] lsm stacking v0.2: actual stacker module

out one way lsm removal could be supported. This will likely be added to the Documentation/stacker.txt file. thanks, -serge The following describes the locking used by the lsm stacker as of July 1, 2005: Things which require locking include: 1. module list 2. per-kernel-object sec

Re: [PATCH] securityfs

k a function pointer to an update() or validate() function. I'll try to do something like that later today or tomorrow. thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http:

Re: [PATCH] securityfs

Quoting Greg KH ([EMAIL PROTECTED]): > > Or is there a better way to do this? > > Look at how debugfs uses the libfs code. We should not need to add > these handlers to securityfs. Ah, ok, thanks. I think I've got it - will send out a new patch tomorrow. thanks, -serge -

Re: [PATCH] securityfs

out cleaner than my original patch. This patch against seclvl moves the filesystem interface from sysfs to the securityfs proposed by Greg KH. thanks, -serge Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]> -- seclvl.c | 251 +++--

Re: [PATCH] securityfs

e this patch does? The error I get without the fs.h patch is: security/seclvl.c: In function `seclvl_file_ops_open': security/seclvl.c:186: warning: int format, different type arg (arg 2) thanks, -serge -- include/linux/fs.h |1 security/seclvl.c | 228 -

Re: [patch 0/15] lsm stacking v0.3: intro

file, and move those declarations into security.h. They were just in their own file because Stephen had pointed out that switching between stacker and non-stacker would cause too much code to be recompiled. thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-ker

Re: [patch 0/15] lsm stacking v0.3: intro

with ps - "fixing" that is obviously not acceptable. Is there another suggestion for how to handle this, in such a way that ps would show info for >1 module? Is there any example where the current behavior is actually a problem - two modules which it makes sense to stack, w

Re: [patch 0/15] lsm stacking v0.3: intro

t; > it. If I just ditch those, then I can probably ditch the whole > > Esp since James' suggestion would impact it. I'd imagine you would always want > array[0] for this case, no? Actually I don't think that's even needed - I just wasn't thinking right while add

Re: [patch 0/15] lsm stacking v0.3: intro

Quoting Tony Jones ([EMAIL PROTECTED]): > OK. As long as you are aware of it, which it sounds like you are. > > Serge, I think it should be documented as a known issue. Ok. > > Clearly this is limiting, but then so is the one line per process you > > get with ps - "fix

Re: [PATCH] Stacker - single-use static slots

but it is an API change... > > API change is no big deal. Seems useful to get index value so you can > do optimized retrieve later. But, I don't see it useful to request that > way. Just register, get index, if index == last slot, lookup hits list. If we do switch to all LSMs

Re: [PATCH] capabilities: introduce per-process capability bounding set (v10)

Quoting KaiGai Kohei ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: > > The capability bounding set is a set beyond which capabilities > > cannot grow. Currently cap_bset is per-system. It can be > > manipulated through sysctl, but only init can add capabilities. > > R

Re: [PATCH] capabilities: introduce per-process capability bounding set (v10)

Quoting KaiGai Kohei ([EMAIL PROTECTED]): > Andrew Morgan wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> KaiGai Kohei wrote: >>> Serge, >>> >>> Please tell me the meanings of the following condition. >>> >>>>

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

gt; so that they could be composed. > > Once you have stacking then it actually at times will make sense to have > security modules that do one very precise thing and do it well. Hey - I thought it was the other way around? :) -serge - To unsubscribe from this list: send the line &qu

Re: [PATCH] rlim in proc//status

Quoting Clifford Wolf ([EMAIL PROTECTED]): > Hi, > > because I needed it already twice in two different projects this week: the > following patch adds rlim (ulimits) output to /proc//status. > > Please let me know if there is another (already existing) way of accessing > this information easy (i.

Re: [RFC/PATCH 2/8] revoke: inode revoke lock V7

Quoting Pekka J Enberg ([EMAIL PROTECTED]): > From: Pekka Enberg <[EMAIL PROTECTED]> > > The revoke operation cannibalizes the revoked struct inode and removes it from > the inode cache thus forcing subsequent callers to look up the real inode. > Therefore we must make sure that while the revoke o

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Quoting Tetsuo Handa ([EMAIL PROTECTED]): > Hello. > > Serge E. Hallyn wrote: > > But your requirements are to ensure that an application accessing a > > device at a well-known location get what it expect. > > Yes. That's the purpose of this filesystem. >

Re: [POSSIBLE BUG]: tg3 network is "lost"

Ok i found the reason, wasn't TG3 driver problem, but firmware. If it can help someone else: http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=PSD_EU050629_CW01&prodTypeId=329290&prodSeriesId=407731 > > > > > > > > > - To unsubscribe from this list: send the

Network "freeze/lost"

Hello everybody. First of all, excus emy (poor) english, i'm french. I have a big trouble with several server, web server. They are debian sarge based. Program that run on it are principally Apache2, PHP5, Zend cluster with session management, Postfix and NFS client Theses servers work we

[POSSIBLE BUG]: tg3 network is "lost"

Hello everybody. This is a second post, because title was wrong on the first post. Please excuse my english, i'm french. I have a big trouble with several server, web server. They are all debian sarge based. Program that run on tem are principally Apache2, PHP5, Zend cluster with session managem

Re: [PATCHv5] procfs: show hierarchy of pid namespace

If pidns_list_add fails, the get_pid taken in the caller leaks. It's not clear to me that the loop in 'if curns' will always end in a list_add_tail, and if not the get_pid leaks. It does look like it should, but something to catch the unexpected failure (especially after someone modifies that

Re: [RFC PATCH] userns: Disallow setgroups unless the gid_map writer is privileged

iiuc this should be ok for lxc since it always has a privileged map writer. (sorry I'm pretty much afk until dec 10) Thanks, - sergeOn 11/28/14 16:53 Andy Lutomirski wrote: Classic unix permission checks have an interesting feature. The group permissions for a file can be set to less than the o

Re: [CFT] Can I get some Tested-By's on this series?

sorry, I've only been back from the road the days... Two tries at compiling have failed (infrastructure problems, not your set), hoping to fire of another build tonight.On 12/10/14 16:48 Serge Hallyn wrote: Quoting Eric W. Biederman (ebied...@xmission.com): > > Will people please

[PATCH 2/8] sched: new clone flag CLONE_NEWCGROUP for cgroup namespace

From: Aditya Kali CLONE_NEWCGROUP will be used to create new cgroup namespace. Signed-off-by: Aditya Kali Acked-by: Serge Hallyn --- include/uapi/linux/sched.h |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h

[PATCH 4/8] cgroup: export cgroup_get() and cgroup_put()

From: Aditya Kali move cgroup_get() and cgroup_put() into cgroup.h so that they can be called from other places. Signed-off-by: Aditya Kali Acked-by: Serge Hallyn --- include/linux/cgroup.h | 21 + kernel/cgroup.c| 22 -- 2 files changed

[PATCH 8/8] cgroup: Add documentation for cgroup namespaces

From: Aditya Kali Signed-off-by: Aditya Kali Signed-off-by: Serge Hallyn --- Documentation/cgroups/namespace.txt | 142 +++ 1 file changed, 142 insertions(+) create mode 100644 Documentation/cgroups/namespace.txt diff --git a/Documentation/cgroups

[PATCH 7/8] cgroup: mount cgroupns-root when inside non-init cgroupns

management tools to run inside the containers without depending on any global state. In order to support this, a new kernfs api is added to lookup the dentry for the cgroupns-root. Signed-off-by: Aditya Kali Acked-by: Serge E. Hallyn --- fs/kernfs/mount.c | 48

[PATCH 3/8] cgroup: add function to get task's cgroup

From: Aditya Kali get_task_cgroup() returns the (reference counted) cgroup of the given task. Signed-off-by: Aditya Kali Acked-by: Serge Hallyn --- include/linux/cgroup.h |1 + kernel/cgroup.c| 25 + 2 files changed, 26 insertions(+) diff --git a

CGroup Namespaces (v4)

ption parsing 4. Restored ACKs from Serge Hallyn from v1 on few patches that have not changed since then. Changes from V1: 1. No pinning of processes within cgroupns. Tasks can be freely moved across cgroups even outside of their cgroupns-root. Usual DAC/MAC policies apply as before. 2.

[PATCH 1/8] kernfs: Add API to generate relative kernfs path

From: Aditya Kali The new function kernfs_path_from_node() generates and returns kernfs path of a given kernfs_node relative to a given parent kernfs_node. Signed-off-by: Aditya Kali Acked-by: Serge E. Hallyn --- fs/kernfs/dir.c| 195

[PATCH 6/8] cgroup: cgroup namespace setns support

attaching process under the target cgroupns-root. Signed-off-by: Aditya Kali Acked-by: Serge E. Hallyn --- kernel/cgroup_namespace.c | 23 --- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c index ef20777

[PATCH 5/8] cgroup: introduce cgroup namespaces

-tools (like libcontainer, lxc, lmctfy, etc.) to create completely virtualized containers without leaking system level cgroup hierarchy to the task. This patch only implements the 'unshare' part of the cgroupns. Signed-off-by: Aditya Kali Signed-off-by: Serge Hallyn --- fs/proc/na

Re: [RFC] capabilities: add capability cgroup controller

apologies for top posting, this phone doesn't support inline) Where are you preventing less privileged tasks from limiting the caps of a more privileged task? It looks like you are relying on the cgroupfs for that? Overall I'm not a fan of this for several reasons. Can you tell us precisely w

Re: [Lxc-users] Containers slow to start after 1600

increment - so 1123 seconds to create 5000 veth pairs) > >Quoting Benoit Lourdelet (blour...@juniper.net): > >> Hello Serge, > >> > >> I put together a small table, running your script for various values : > >> > >> Time are in seconds, > &

Re: [PATCH v5 9/9] devcg: propagate local changes down the hierarchy

g is > propagated. Or did you mean something else? Ah, yes, I didn't understand that correctly, thanks. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.k

Re: [PATCH] kernel: arg2 is unsigned long which is never < 0

older than branch 2. > for features: > branch 1 is for functional feature and bug fix, > branch 2 is for printing warning and beautifying code. > > it seems: > branch 2 did not notice the branch 1, before it performs. > if it noticed, it is meanless to define

Re: [PATCH v6 9/9] devcg: propagate local changes down the hierarchy

Quoting Aristeu Rozanski (a...@redhat.com): > On Mon, Feb 11, 2013 at 06:52:39PM +0000, Serge E. Hallyn wrote: > > > getting rid of local settings would buy more simplicity > > > > (Not sure which you mean here by 'getting rid of local settings') > > no

Re: [PATCH 1/1] kernel/nsproxy.c: Improving a snippet of code.

Quoting Raphael S.Carvalho (raphael.sc...@gmail.com): > It seems GCC generates a better code in that way, so I changed that statement. > Btw, they have the same semantic, so I'm sending this patch due to > performance issues. > > Signed-off-by: Raphael S.Carvalho Acked

Re: For review: user_namespaces(7) man page

ewuidmap(1) and newgidmap(1) might be good. thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] module: allow loading module from fd

g new or crazy interfaces > or further complicating the ELF loader. Instead, just use the existing > syscall in a new way. Tools using the fd argument style can trivially > downgrade to the blob argument style when they see an EFAULT error. > > Signed-off-by: Kees

Re: [PATCH 2/2] security: introduce kernel_module_from_file hook

Quoting Kees Cook (keesc...@chromium.org): > Now that kernel module origins can be reasoned about, provide a hook to > the LSMs to make policy decisions about the module file. > > Signed-off-by: Kees Cook Acked-by: Serge E. Hallyn > --- > include/linux/security.h | 11 +++

Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

should be removed. As a first step, remove it from being > > listed, and default it to on. Once it has been removed from all > > subsystem Kconfigs, it will be dropped entirely. > > > > CC: Greg KH > > CC: "Eric W. Biederman" > > CC: Serge Hallyn

Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

ways enabled by default. As agreed during the Linux kernel > > > > > > summit, it should be removed. As a first step, remove it from being > > > > > > listed, and default it to on. Once it has been removed from all > > > > > > subsystem Kconfig

Re: [PATCH] proc: don't show nonexistent capabilities

Drat, thanks Andrew, I thought I had a testcase for that in LTP, but apparently not. capsh --caps="all=eip" -- -c /bin/bash indeed fails with this patch (and succeeds without). So Nacked-by: Serge Hallyn since this is a much more common idiom, enough so that I'm not willing t

Re: [PATCH v6 01/10] ipc: remove forced assignment of selected message

Quoting Stanislav Kinsbursky (skinsbur...@parallels.com): > This is a cleanup patch. The assignment is redundant. > > Signed-off-by: Stanislav Kinsbursky Acked-by: Serge E. Hallyn > --- > ipc/msg.c |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) > >

Re: [PATCH v6 03/10] ipc: segment key change helper introduced

lock the segment during check that new key is > not used. > > Signed-off-by: Stanislav Kinsbursky Acked-by: Serge E. Hallyn > --- > ipc/compat.c |6 ++ > ipc/util.c | 51 --- > ipc/util.h |2 ++ > 3 file

Re: [PATCH v6 04/10] ipc: add new SHM_SET command for sys_shmctl() call

EEXIST is > returned. > > Signed-off-by: Stanislav Kinsbursky Looks sane (modulo 'fallsthrough' comment already requested) Acked-by: Serge E. Hallyn > --- > include/uapi/linux/shm.h |1 + > ipc/compat.c |1 + > ipc/shm.c

Re: [PATCH v6 05/10] ipc: add new MSG_SET command for sys_msgctl() call

EEXIST is > returned. > > Signed-off-by: Stanislav Kinsbursky Acked-by: Serge E. Hallyn > --- > include/uapi/linux/msg.h |1 + > ipc/compat.c |1 + > ipc/msg.c | 13 +++-- > security/selinux/hooks.c |1 + > secu

Re: [PATCH v6 06/10] glge driver: rename internal SEM_SET macro to SEM_INIT

em calls are originally created by replacing "IPC_" part by > "SEM_"("MSG_", "SHM_") part. > So, I'm hoping, that this change doesn't really matters for "QLogic qlge NIC Can't speak for the driver maintainer, but it does look sane. Ack

Re: [PATCH v6 07/10] ipc: add new SEM_SET command for sys_semctl() call

EEXIST is > returned. > > Signed-off-by: Stanislav Kinsbursky Acked-by: Serge E. Hallyn (again, modulo requested /* fallthrough */ comment ) > --- > include/uapi/linux/sem.h |1 + > ipc/compat.c |1 + > ipc/sem.c | 10

Re: [PATCH v6 09/10] IPC: message queue copy feature introduced

Quoting Stanislav Kinsbursky (skinsbur...@parallels.com): > This patch is required for checkpoint/restore in userspace. > IOW, c/r requires some way to get all pending IPC messages without deleting > them from the queue (checkpoint can fail and in this case tasks will be > resumed, > so queue have

Re: [PATCH 155/193] init: remove CONFIG_EXPERIMENTAL

Quoting Kees Cook (keesc...@chromium.org): > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: "Eric W. Biederman" > CC: Serge Hallyn > CC: &

Re: [PATCH 155/193] init: remove CONFIG_EXPERIMENTAL

Quoting Kees Cook (keesc...@chromium.org): > On Wed, Oct 24, 2012 at 6:48 AM, Serge Hallyn > wrote: > > Quoting Kees Cook (keesc...@chromium.org): > >> This config item has not carried much meaning for a while now and is > >> almost always enabled by default. As

Re: [PATCH] device_cgroup: fix unchecked cgroup parent usage

ot directory so I didn't catch it on my > regular tests. > > Andrew, Tejun, this patch needs to make Linus tree ASAP or a revert for > 4cef7299b4786879a3e113e84084a72b24590c5b. > > Cc: Andrew Morton > Cc: Tejun Heo > Cc: Li Zefan > Cc: James Morris > Cc: Pav

Re: [PATCH v2] proc: add "Seccomp" to status

te of running processes, there should be a way to > externally examine the seccomp mode. ("Did this build of Chrome end up > using seccomp?" "Did my distro ship ssh with seccomp enabled?") > > This adds the "Seccomp" line to /proc/$pid/status. > >

Re: [RFC] cgroup: deprecate clone_children

Quoting Tejun Heo (t...@kernel.org): > clone_children makes cgroup invoke ->post_clone() callback if it > exists and sets CGRP_CLONE_CHILDREN. ->post_clone(), while being > named generically, is only supposed to copy configuration from its > parent. > > This is an entirely convenience feature whi

Re: [PATCH V2] poweroff: fix bug in orderly_poweroff

Quoting Feng Hong (hongf...@marvell.com): > Hi, Serge, > > I am just a graduate and it's my first time to send a patch to opensource, so > thank you very much for reminding me the "changelog affairs", it seems this > patch has been added to -mm tree as attached

Re: [PATCH 05/14] userns: Convert hostfs to use kuid and kgid where appropriate

Quoting Richard Weinberger (rich...@nod.at): > Am 21.09.2012 02:28, schrieb Eric W. Biederman: > > From: "Eric W. Biederman" > > > > Cc: Jeff Dike > > Cc: Richard Weinberger > > Acked-by: Serge Hallyn > > Signed-off-by: Eric W. Biederman >

Re: [PATCH v5 01/10] ipc: remove forced assignment of selected message

Quoting Stanislav Kinsbursky (skinsbur...@parallels.com): > This is a cleanup patch. The assignment is redundant. > > Signed-off-by: Stanislav Kinsbursky > --- > ipc/msg.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/ipc/msg.c b/ipc/msg.c > index 7385de2..f3bfbb

Re: [PATCH 04/14] userns: Convert selinux to use kuid and kgid where appropriate

Quoting Eric W. Biederman (ebied...@xmission.com): > From: "Eric W. Biederman" > > Cc: Stephen Smalley > Cc: James Morris > Cc: Eric Paris Acked-by: Serge E. Hallyn > Signed-off-by: "Eric W. Biederman" > --- > security/selinux/selinuxfs.c |

Re: [PATCH 10/14] userns: Convert s390 hypfs to use kuid and kgid where appropriate

Quoting Eric W. Biederman (ebied...@xmission.com): > From: "Eric W. Biederman" > > Cc: Martin Schwidefsky > Cc: Heiko Carstens Acked-by: Serge E. Hallyn > Signed-off-by: "Eric W. Biederman" > --- > arch/s390/hypfs/inode.c | 20 ++-

Re: [PATCH 13/14] userns: On ia64 deal with current_uid and current_gid being kuid and kgid

Quoting Eric W. Biederman (ebied...@xmission.com): > From: "Eric W. Biederman" > > These ia64 uses of current_uid and current_gid slipped through the > cracks when I was converting everything to kuids and kgids convert > them now. > > Cc: Tony Luck > Cc: Feng

Re: [PATCH 12/14] userns: On ppc convert current_uid from a kuid before printing.

Quoting Eric W. Biederman (ebied...@xmission.com): > From: "Eric W. Biederman" > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras Acked-by: Serge E. Hallyn > Signed-off-by: "Eric W. Biederman" > --- > arch/powerpc/mm/fault.c |2 +- > 1

Re: [PATCH 11/14] userns: Convert s390 getting uid and gid system calls to use kuid and kgid

m calls slipped through the cracks in my first > round of converstions :( > > Cc: Martin Schwidefsky > Cc: Heiko Carstens Acked-by: Serge E. Hallyn > Signed-off-by: Eric W. Biederman > --- > arch/s390/kernel/compat_linux.c | 36

[PATCH] Make sure to wake reaper

, to force it to re-test the pidns->nr_hashed = init_pids test. Note that this is more like what __unhash_process() used to do before af4b8a83add95ef40716401395b44a1b579965f4. Signed-off-by: Serge Hallyn Cc: "Eric W. Biederman" --- kernel/pid.c | 4 1 file changed, 4 insertions(

Re: [PATCH] security: allow Yama to be unconditionally stacked

stead of having multiple > distributions (or LSM authors) carrying these patches, just allow Yama > to be called unconditionally when selected by the new CONFIG. I don't really like having both the STACKED and non-stacked paths. But I don't have a good alternative. > Signed-off-by: Kee

Re: [PATCH] proc: don't show nonexistent capabilities (v2)

his case user cannot set all=eip. This patch cleans up non-existent > > capabilities from content of /proc/pid/status > > > > Cc: Andrew G. Morgan > > Cc: Serge Hallyn Basic capsh tests seem to have no problem with it. Thanks, Andrew. Reviewed-by: Serge E. Hallyn >

[PATCH] dev_change_net_namespace: send a KOBJ_REMOVED/KOBJ_ADD

KOBJ_ADD to new netns. There will then be a _MOVE event from the device_rename() call, but that should be innocuous. Signed-off-by: Serge Hallyn Acked-by: "Eric W. Biederman" Acked-by: Daniel Lezcano --- net/core/dev.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/net/co

Re: [RFC] Capabilities still can't be inherited by normal programs

Quoting Andy Lutomirski (l...@amacapital.net): > On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> >> d) If I really wanted, I could emulate execve without actually doing > >> >> exec

Re: [RFC] Capabilities still can't be inherited by normal programs

Quoting Andy Lutomirski (l...@amacapital.net): > On Wed, Dec 5, 2012 at 1:05 PM, Serge Hallyn > wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn wrote: > >> > Quoting Andy Lutomirski (l...@amacapita

Re: [PATCH 1/4] cgroup: fix invalid rcu dereference

hread_helper+0x4/0x10 > [] ? retint_restore_args+0xe/0xe > [] ? kthread_create_on_node+0x140/0x140 > [] ? gs_change+0xb/0xb > > Cc: Dave Jones > Cc: Andrew Morton > Cc: Tejun Heo > Cc: Li Zefan > Cc: James Morris > Cc: Pavel Emelyanov > Cc: Serge Hallyn A

Re: [PATCH 2/4] device_cgroup: rename deny_all to behavior

eo > Cc: Li Zefan > Cc: James Morris > Cc: Pavel Emelyanov > Cc: Serge Hallyn Acked-by: Serge E. Hallyn > Cc: Jiri Slaby > Signed-off-by: Aristeu Rozanski > > --- > security/device_cgroup.c | 25 ++--- > 1 file changed, 14 insert

Re: [PATCH 3/4] device_cgroup: stop using simple_strtoul()

Cc: Tejun Heo > Cc: Li Zefan > Cc: James Morris > Cc: Pavel Emelyanov > Cc: Serge Hallyn Acked-by: Serge E. Hallyn > Cc: Jiri Slaby > Signed-off-by: Aristeu Rozanski > > --- > security/device_cgroup.c | 28 ++-- > 1 file changed,

Re: [PATCH 4/4] device_cgroup: add proper checking when changing default behavior

Quoting Aristeu Rozanski (a...@redhat.com): > Before changing a group's default behavior to ALLOW, we must check if its > parent's behavior is also ALLOW. > > Cc: Tejun Heo > Cc: Li Zefan > Cc: James Morris > Cc: Pavel Emelyanov > Cc: Serge Hallyn Acked-by:

Re: [PATCH] Document how capability bits work

think a pointer to the capabilities.7 man page would be better. (plus, if you feel they are needed, updates to the man page) (I'll refrain from detailed review of the contents until this is discussed.) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&

Re: [PATCH] Document how capability bits work

ly so selinux can mess with it, plus The bounding set was in large part a workaround for the absence of the user namespace (and, at the time, the devices cgroup). (Now libcap-ng uses it to try and make capabilities generally easier to use.) -serge -- To unsubscribe from this list: send the line &qu

Re: [RFC] Capabilities still can't be inherited by normal programs

security.selinux xattrs. The answer as there could be a good set of tools to set and report the system wide state. In fact, libcap-ng provides such tools, to list the file capabilities throughout the system and capabilities in use by all running programs. -serge -- To unsubscribe from t

Re: [RFC] Capabilities still can't be inherited by normal programs

ect Andrew meant True to the first two sentences, not the last parenthesized one?) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Capabilities still can't be inherited by normal programs

estion of "how do I easily figure out what caps I need to run my program." A few years ago I pointed to this (perhaps in mostly private emails, don't recall) as something to be solved, but the solution escapes me. -serge -- To unsubscribe from this list: send the line "unsubscrib

Re: [RFC] Capabilities still can't be inherited by normal programs

Quoting Casey Schaufler (ca...@schaufler-ca.com): > On 12/10/2012 6:59 AM, Serge Hallyn wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> It's especially bad because granting CAP_DAC_READ_SEARCH to user "foo" > >> doesn't mean a

Re: [PATCH] Yama: add RCU to drop read locking

Quoting Kees Cook (keesc...@chromium.org): > Stop using spinlocks in the read path. Add RCU list to handle the readers. Looks good to me. BTW, kfree_rcu is neat :) Reviewed-by: Serge E. Hallyn > Signed-off-by: Kees Cook > --- > security/yama/yama_

Re: [PATCH 1/2] cgroup: s/CGRP_CLONE_CHILDREN/CGRP_CPUSET_CLONE_CHILDREN/

ct that and update documentation. Also, drop > clone_children() wrapper in cgroup.c. The thin wrapper is used only a > few times and one of them will go away soon. > > Signed-off-by: Tejun Heo Thanks. (both) Acked-by: Serge E. Hallyn > Cc: Glauber Costa > --- > These two pat

Re: [PATCH] proc: pid/status: show all supplementary groups

annoying to read. So on the one hand adding a '...' in /proc/self/status after 32, and adding a /proc/$$/creds file seems more pleasant, but then you get into the whole adding files to /proc kerfuffle, so... Acked-by: Serge E. Hallyn > Cc: sta...@vger.kernel.org > --- > fs/pr

Re: [PATCH] userns: Allow unprivileged reboot

Thanks, Li. fwiw, Acked-by: Serge E. Hallyn -serge > --- > kernel/sys.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/sys.c b/kernel/sys.c > index 265b376..24d1ef5 100644 > --- a/kernel/sys.c > +++ b/kernel/sys.c > @@

Re: [PATCH review 03/16] userns: Allow chown and setgid preservation

he current user namespace. > > - Allow perserving setgid when changing an inode if CAP_FSETID is > present in the current user namespace and the owner of the file has > a mapping into the current user namespace. > > Signed-off-by: "Eric W. Biederman" Acked-by: Serge E

Re: [PATCH review 11/16] procfs: Print task uids and gids in the userns that opened the proc file

gned-off-by: "Eric W. Biederman" Acked-by: Serge E. Hallyn > --- > fs/proc/array.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/proc/array.c b/fs/proc/array.c > index c1c207c..5544342 100644 > --- a/fs/proc/array.c > +++

Re: [PATCH review 12/16] userns: For /proc/self/{uid, gid}_map derive the lower userns from the struct file

Quoting Eric W. Biederman (ebied...@xmission.com): > From: "Eric W. Biederman" > > To keep things sane in the context of file descriptor passing derive the > user namespace that uids are mapped into from the opener of the file > instead of from current. > > When writing to the maps file the lowe

  1   2   3   4   5   6   7   8   9   10   >