Re: [PATCH v4 09/11] smack: namespace groundwork

On czw, 2015-10-15 at 15:38 +0800, Hillf Danton wrote: > > > > +static inline void smack_userns_free(struct user_namespace *ns) > > +{ > > + struct smack_ns *snsp = ns->security; > > + struct smack_known *skp; > > + struct smack_known_ns *sknp, *n; > > + > > +

Re: [PATCH v4] Smack: limited capability for changing process label

On 10/15/2015 12:48 AM, Rafał Krypa wrote: > On 2015-10-14 17:54, Rafal Krypa wrote: >> From: Zbigniew Jasinski >> >> This feature introduces new kernel interface: >> >> - /relabel-self - for setting transition labels list >> >> This list is used to control smack label

Re: GPF in keyring_destroy

Dmitry Vyukov wrote: > RAX: ff82 This is the value that matters. It would appear to be -ENOKEY and would be in key->type_data.reject_error, I think. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a

[PATCH] keys: change member variable name

key->description and key->index_key.description are same because they are unioned. But, for readability, using same name for duplication and validation seems better. Signed-off-by: Insu Yun --- security/keys/key.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] keys: correctly check failed allocation for kmemdup

kmemdup return value is saved in 'key->index_key.description', not 'key->descrption' and kmemdup can be failed in memory pressure. Therefore, key->index_key.description should be checked. Signed-off-by: Insu Yun --- security/keys/key.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH] keys: correctly check failed allocation for kmemdup

Insu Yun wrote: > Thanks David. Then it is not a bug. > It's a pure question. > Why use different name for allocation and check? > For me, it is quite confusing. Either I didn't notice at the time, or the shorter variant is the original. If you want to give me a patch

Re: GPF in keyring_destroy

Does the attached patch fix it for you? David --- commit a7609e0bb3973d6ee3c9f1ecd0b6a382d99d6248 Author: David Howells Date: Thu Oct 15 17:21:37 2015 +0100 KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring The following sequence of

Re: [PATCH v2 7/7] Smack: Handle labels consistently in untrusted mounts

On Wed, Oct 14, 2015 at 10:46:47PM -0700, Casey Schaufler wrote: > On 10/13/2015 10:04 AM, Seth Forshee wrote: > > The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled > > differently in untrusted mounts. This is confusing and > > potentically problematic. Change this to handle them