linux-next: manual merge of the security tree with Linus' tree

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

Hi James,

Today's linux-next merge of the security tree got conflicts in
security/keys/keyring.c and security/keys/process_keys.c between commit
9a56c2db49e7 ("userns: Convert security/keys to the new userns
infrastructure") from Linus' tree and commit 96b5c8fea6c0 ("KEYS: Reduce
initial permissions on keys") from the security tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc security/keys/keyring.c
index 6e42df1,9270ba0..0000000
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@@ -256,9 -256,9 +256,9 @@@ error
  /*
   * Allocate a keyring and link into the destination keyring.
   */
 -struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid,
 +struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
- 			  const struct cred *cred, unsigned long flags,
- 			  struct key *dest)
+ 			  const struct cred *cred, key_perm_t perm,
+ 			  unsigned long flags, struct key *dest)
  {
  	struct key *keyring;
  	int ret;
diff --cc security/keys/process_keys.c
index a58f712,b58d938..0000000
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@@ -45,15 -46,15 +45,17 @@@ int install_user_keyrings(void
  	struct user_struct *user;
  	const struct cred *cred;
  	struct key *uid_keyring, *session_keyring;
+ 	key_perm_t user_keyring_perm;
  	char buf[20];
  	int ret;
 +	uid_t uid;
  
+ 	user_keyring_perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_ALL;
  	cred = current_cred();
  	user = cred->user;
 +	uid = from_kuid(cred->user_ns, user->uid);
  
 -	kenter("%p{%u}", user, user->uid);
 +	kenter("%p{%u}", user, uid);
  
  	if (user->uid_keyring) {
  		kleave(" = 0 [exist]");
@@@ -72,9 -73,9 +74,9 @@@
  
  		uid_keyring = find_keyring_by_name(buf, true);
  		if (IS_ERR(uid_keyring)) {
 -			uid_keyring = keyring_alloc(buf, user->uid, (gid_t) -1,
 +			uid_keyring = keyring_alloc(buf, user->uid, INVALID_GID,
- 						    cred, KEY_ALLOC_IN_QUOTA,
- 						    NULL);
+ 						    cred, user_keyring_perm,
+ 						    KEY_ALLOC_IN_QUOTA, NULL);
  			if (IS_ERR(uid_keyring)) {
  				ret = PTR_ERR(uid_keyring);
  				goto error;
@@@ -88,8 -89,9 +90,9 @@@
  		session_keyring = find_keyring_by_name(buf, true);
  		if (IS_ERR(session_keyring)) {
  			session_keyring =
 -				keyring_alloc(buf, user->uid, (gid_t) -1,
 +				keyring_alloc(buf, user->uid, INVALID_GID,
- 					      cred, KEY_ALLOC_IN_QUOTA, NULL);
+ 					      cred, user_keyring_perm,
+ 					      KEY_ALLOC_IN_QUOTA, NULL);
  			if (IS_ERR(session_keyring)) {
  				ret = PTR_ERR(session_keyring);
  				goto error_release;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

Hi James,

Today's linux-next merge of the security tree got a conflict in
security/keys/keyctl.c between commit 9a56c2db49e7 ("userns: Convert
security/keys to the new userns infrastructure") from Linus' tree and
commit 3a50597de863 ("KEYS: Make the session and process keyrings
per-thread") from the security tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc security/keys/keyctl.c
index 5d34b4e,6d9d0c7..0000000
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@@ -1535,9 -1527,9 +1536,9 @@@ long keyctl_session_to_parent(void
  		goto unlock;
  
  	/* the keyrings must have the same UID */
- 	if ((pcred->tgcred->session_keyring &&
- 	     !uid_eq(pcred->tgcred->session_keyring->uid, mycred->euid)) ||
- 	    !uid_eq(mycred->tgcred->session_keyring->uid, mycred->euid))
+ 	if ((pcred->session_keyring &&
 -	     pcred->session_keyring->uid != mycred->euid) ||
 -	    mycred->session_keyring->uid != mycred->euid)
++	     !uid_eq(pcred->session_keyring->uid, mycred->euid)) ||
++	    !uid_eq(mycred->session_keyring->uid, mycred->euid))
  		goto unlock;
  
  	/* cancel an already pending keyring replacement */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

Hi James,

Today's linux-next merge of the security tree got a conflict in
net/dns_resolver/dns_key.c between commit c6089735e724 ("userns: net:
Call key_alloc with GLOBAL_ROOT_UID, GLOBAL_ROOT_GID instead of 0, 0")
from Linus' tree and commit f8aa23a55f81 ("KEYS: Use keyring_alloc() to
create special keyrings") from the security tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/dns_resolver/dns_key.c
index 8aa4b11,b53bb4a..0000000
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@@ -259,11 -259,10 +259,11 @@@ static int __init init_dns_resolver(voi
  	if (!cred)
  		return -ENOMEM;
  
- 	keyring = key_alloc(&key_type_keyring, ".dns_resolver",
 -	keyring = keyring_alloc(".dns_resolver", 0, 0, cred,
 -				(KEY_POS_ALL & ~KEY_POS_SETATTR) |
 -				KEY_USR_VIEW | KEY_USR_READ,
 -				KEY_ALLOC_NOT_IN_QUOTA, NULL);
++	keyring = keyring_alloc(".dns_resolver",
 +			    GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
 +			    (KEY_POS_ALL & ~KEY_POS_SETATTR) |
 +			    KEY_USR_VIEW | KEY_USR_READ,
 +			    KEY_ALLOC_NOT_IN_QUOTA);
  	if (IS_ERR(keyring)) {
  		ret = PTR_ERR(keyring);
  		goto failed_put_cred;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Hi James,

On Wed, 17 Oct 2012 11:41:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the security tree got a conflict in
> net/dns_resolver/dns_key.c between commit c6089735e724 ("userns: net:
> Call key_alloc with GLOBAL_ROOT_UID, GLOBAL_ROOT_GID instead of 0, 0")
> from Linus' tree and commit f8aa23a55f81 ("KEYS: Use keyring_alloc() to
> create special keyrings") from the security tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc net/dns_resolver/dns_key.c
> index 8aa4b11,b53bb4a..0000000
> --- a/net/dns_resolver/dns_key.c
> +++ b/net/dns_resolver/dns_key.c
> @@@ -259,11 -259,10 +259,11 @@@ static int __init init_dns_resolver(voi
>   	if (!cred)
>   		return -ENOMEM;
>   
> - 	keyring = key_alloc(&key_type_keyring, ".dns_resolver",
>  -	keyring = keyring_alloc(".dns_resolver", 0, 0, cred,
>  -				(KEY_POS_ALL & ~KEY_POS_SETATTR) |
>  -				KEY_USR_VIEW | KEY_USR_READ,
>  -				KEY_ALLOC_NOT_IN_QUOTA, NULL);
> ++	keyring = keyring_alloc(".dns_resolver",
>  +			    GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
>  +			    (KEY_POS_ALL & ~KEY_POS_SETATTR) |
>  +			    KEY_USR_VIEW | KEY_USR_READ,
>  +			    KEY_ALLOC_NOT_IN_QUOTA);

Oops, there should be a ", NULL" before the closing parenthesis above.  I
fixed that in my tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Hi James,

Today's linux-next merge of the security tree got a conflict in
security/integrity/ima/ima_main.c between commit a7f2a366f623 ("ima:
fallback to MODULE_SIG_ENFORCE for existing kernel module syscall") from
Linus' tree and commit 750943a30714 ("ima: remove enforce checking
duplication") from the security tree.

I think I fixed it up (see below).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc security/integrity/ima/ima_main.c
index dba965d,cd00ba3..0000000
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@@ -291,18 -275,10 +275,18 @@@ EXPORT_SYMBOL_GPL(ima_file_check)
   */
  int ima_module_check(struct file *file)
  {
- 	int rc = 0;
- 
 -	if (!file)
 +	if (!file) {
 +		if (ima_appraise & IMA_APPRAISE_MODULES) {
 +#ifndef CONFIG_MODULE_SIG_FORCE
- 			rc = -EACCES;	/* INTEGRITY_UNKNOWN */
++			return -EACCES;	/* INTEGRITY_UNKNOWN */
++#else
++			return 0;
 +#endif
 +		}
- 	} else
- 		rc = process_measurement(file, file->f_dentry->d_name.name,
- 					 MAY_EXEC, MODULE_CHECK);
- 	return (ima_appraise & IMA_APPRAISE_ENFORCE) ? rc : 0;
+ 		return -EACCES;	/* INTEGRITY_UNKNOWN */
++	}
+ 	return process_measurement(file, file->f_dentry->d_name.name,
+ 				   MAY_EXEC, MODULE_CHECK);
  }
  
  static int __init init_ima(void)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Mimi Zohar]

On Mon, 2013-01-21 at 13:12 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> Today's linux-next merge of the security tree got a conflict in
> security/integrity/ima/ima_main.c between commit a7f2a366f623 ("ima:
> fallback to MODULE_SIG_ENFORCE for existing kernel module syscall") from
> Linus' tree and commit 750943a30714 ("ima: remove enforce checking
> duplication") from the security tree.
> 
> I think I fixed it up (see below).

Sorry Stephen, the merged result should look like what's contained in
linux-integrity/next-upstreamed-patches:

int ima_module_check(struct file *file)
{
        if (!file) {
                if ((ima_appraise & IMA_APPRAISE_MODULES) &&
                    (ima_appraise & IMA_APPRAISE_ENFORCE)) {
#ifndef CONFIG_MODULE_SIG_FORCE
                        return -EACCES; /* INTEGRITY_UNKNOWN */
#endif
                }
                return 0;
        }
        return process_measurement(file, file->f_dentry->d_name.name,
                                   MAY_EXEC, MODULE_CHECK);
}

thanks,

Mimi

Re: linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Hi Mimi,

On Sun, 20 Jan 2013 22:10:23 -0500 Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>
> Sorry Stephen, the merged result should look like what's contained in
> linux-integrity/next-upstreamed-patches:
> 
> int ima_module_check(struct file *file)
> {
>         if (!file) {
>                 if ((ima_appraise & IMA_APPRAISE_MODULES) &&
>                     (ima_appraise & IMA_APPRAISE_ENFORCE)) {
> #ifndef CONFIG_MODULE_SIG_FORCE
>                         return -EACCES; /* INTEGRITY_UNKNOWN */
> #endif
>                 }
>                 return 0;
>         }
>         return process_measurement(file, file->f_dentry->d_name.name,
>                                    MAY_EXEC, MODULE_CHECK);
> }

OK, I will use that version tomorrow.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Hi James,

Today's linux-next merge of the security tree got a conflict in
lib/digsig.c between commit 7810cc1e7721 ("digsig: Fix memory leakage in
digsig_verify_rsa()") from Linus' tree and commit 26d438457ed1 ("digsig:
remove unnecessary memory allocation and copying") from the security tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc lib/digsig.c
index dc2be7e,0103c5b..0000000
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@@ -162,13 -152,9 +152,11 @@@ static int digsig_verify_rsa(struct ke
  	memset(out1, 0, head);
  	memcpy(out1 + head, p, l);
  
 +	kfree(p);
 +
- 	err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, &len);
- 	if (err)
- 		goto err;
+ 	m = pkcs_1_v1_5_decode_emsa(out1, len, mblen, &len);
  
- 	if (len != hlen || memcmp(out2, h, hlen))
+ 	if (!m || len != hlen || memcmp(m, h, hlen))
  		err = -EINVAL;
  
  err:

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

Hi James,

Today's linux-next merge of the security tree got a conflict in:

  security/yama/yama_lsm.c

between commit:

  5413fcdbe9e7 ("Adding YAMA hooks also when YAMA is not stacked.")

from Linus' tree and commit:

  730daa164e7c ("Yama: remove needless CONFIG_SECURITY_YAMA_STACKED")

from the security tree.

I fixed it up (the latter removed the code updated by the former, so I
just did that) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  kernel/trace/trace_kprobe.c

between commit:

  715fa2fd4c6c ("tracing/kprobe: Check registered state using kprobe")

from Linus' tree and commit:

  e87402c063fd ("lockdown: Lock down tracing and perf kprobes when in confidentiality mode")

from the security tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/trace/trace_kprobe.c
index 9d483ad9bb6c,fcb28b0702b2..000000000000
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@@ -11,9 -11,8 +11,10 @@@
  #include <linux/uaccess.h>
  #include <linux/rculist.h>
  #include <linux/error-injection.h>
+ #include <linux/security.h>
  
 +#include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
 +
  #include "trace_dynevent.h"
  #include "trace_kprobe_selftest.h"
  #include "trace_probe.h"
@@@ -389,7 -416,11 +390,11 @@@ static int __register_trace_kprobe(stru
  {
  	int i, ret;
  
+ 	ret = security_locked_down(LOCKDOWN_KPROBES);
+ 	if (ret)
+ 		return ret;
+ 
 -	if (trace_probe_is_registered(&tk->tp))
 +	if (trace_kprobe_is_registered(tk))
  		return -EINVAL;
  
  	if (within_notrace_func(tk)) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

Today's linux-next merge of the security tree got conflicts in:

  arch/s390/configs/debug_defconfig
  arch/s390/configs/defconfig

between commit:

  3361f3193c74 ("s390: update configs")

from Linus' tree and commit:

  99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")

from the security tree.

I fixed it up (the former removed the CONFIG option updated by the latter)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Hi all,

Just adding a couple of more Cc's

On Wed, 21 Aug 2019 13:01:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the security tree got conflicts in:
> 
>   arch/s390/configs/debug_defconfig
>   arch/s390/configs/defconfig
> 
> between commit:
> 
>   3361f3193c74 ("s390: update configs")
> 
> from Linus' tree and commit:
> 
>   99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
> 
> from the security tree.
> 
> I fixed it up (the former removed the CONFIG option updated by the latter)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  security/integrity/ima/Kconfig

between commit:

  9e1e5d4372d6 ("x86/ima: fix the Kconfig dependency for IMA_ARCH_POLICY")

from Linus' tree and commit:

  99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")

from the security tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/integrity/ima/Kconfig
index 2ced99dde694,32cd25fa44a5..000000000000
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@@ -160,8 -160,7 +160,8 @@@ config IMA_APPRAIS
  
  config IMA_ARCH_POLICY
          bool "Enable loading an IMA architecture specific policy"
-         depends on (KEXEC_VERIFY_SIG && IMA) || IMA_APPRAISE \
 -        depends on KEXEC_SIG || IMA_APPRAISE && INTEGRITY_ASYMMETRIC_KEYS
++        depends on (KEXEC_SIG && IMA) || IMA_APPRAISE \
 +		   && INTEGRITY_ASYMMETRIC_KEYS
          default n
          help
            This option enables loading an IMA architecture specific policy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  arch/s390/configs/performance_defconfig

between commit:

  d1523a8f4b8b ("s390: replace defconfig with performance_defconfig")

from Linus' tree and commit:

  99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")

from the security tree.

I fixed it up (the former removed this file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  security/selinux/include/classmap.h

between commit:

  f4d653dcaa4e ("selinux: implement the security_uring_cmd() LSM hook")

from Linus' tree and commit:

  ed5d44d42c95 ("selinux: Implement userns_create hook")

from the security tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/selinux/include/classmap.h
index 1c2f41ff4e55,0bff55bb9cde..000000000000
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@@ -253,7 -253,9 +253,9 @@@ const struct security_class_mapping sec
  	{ "anon_inode",
  	  { COMMON_FILE_PERMS, NULL } },
  	{ "io_uring",
 -	  { "override_creds", "sqpoll", NULL } },
 +	  { "override_creds", "sqpoll", "cmd", NULL } },
+ 	{ "user_namespace",
+ 	  { "create", NULL } },
  	{ NULL }
    };
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Paul Moore]

On Wed, Aug 31, 2022 at 10:27 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the security tree got a conflict in:
>
>   security/selinux/include/classmap.h
>
> between commit:
>
>   f4d653dcaa4e ("selinux: implement the security_uring_cmd() LSM hook")
>
> from Linus' tree and commit:
>
>   ed5d44d42c95 ("selinux: Implement userns_create hook")
>
> from the security tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc security/selinux/include/classmap.h
> index 1c2f41ff4e55,0bff55bb9cde..000000000000
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@@ -253,7 -253,9 +253,9 @@@ const struct security_class_mapping sec
>         { "anon_inode",
>           { COMMON_FILE_PERMS, NULL } },
>         { "io_uring",
>  -        { "override_creds", "sqpoll", NULL } },
>  +        { "override_creds", "sqpoll", "cmd", NULL } },
> +       { "user_namespace",
> +         { "create", NULL } },
>         { NULL }
>     };

Thanks Stephen, that looks correct.

-- 
paul-moore.com

linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  security/commoncap.c

between commit:

  8cf0a1bc1287 ("capabilities: fix potential memleak on error path from vfs_getxattr_alloc()")

from Linus' tree and commit:

  f6fbd8cbf3ed ("lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths")

from the security tree.

I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Paul Moore]

On Sun, Nov 20, 2022 at 10:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the security tree got a conflict in:
>
>   security/commoncap.c
>
> between commit:
>
>   8cf0a1bc1287 ("capabilities: fix potential memleak on error path from vfs_getxattr_alloc()")
>
> from Linus' tree and commit:
>
>   f6fbd8cbf3ed ("lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths")
>
> from the security tree.
>
> I fixed it up (I just used the latter) and can carry the fix as
> necessary.

That's more or less what I've done with my builds, thanks Stephen.

I asked this on a previous conflict but never received an answer so
I'll ask it one more time: is there a recommended way to notify
linux-next of an upcoming conflict?  I generally notice the merge
conflict within a few minutes of merging the patches into a -next
branch, and fix it shortly afterwards.  I'm happy to provide a
heads-up, and a merge example, but I'm not sure what the process is
for that, if any.  Or, would you simply prefer to notice it yourself?
I'm not bothered either way, I just thought you might appreciate the
heads-up.

-- 
paul-moore.com

Re: linux-next: manual merge of the security tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

Hi Paul,

On Mon, 21 Nov 2022 13:47:18 -0500 Paul Moore <paul@paul-moore.com> wrote:
>
> I asked this on a previous conflict but never received an answer so
> I'll ask it one more time: is there a recommended way to notify
> linux-next of an upcoming conflict?  I generally notice the merge
> conflict within a few minutes of merging the patches into a -next
> branch, and fix it shortly afterwards.  I'm happy to provide a
> heads-up, and a merge example, but I'm not sure what the process is
> for that, if any.  Or, would you simply prefer to notice it yourself?
> I'm not bothered either way, I just thought you might appreciate the
> heads-up.

Sorry about that.  Some maintainers will just send a "heads up" email
with a suggested resolution patch (but I don't get very many).  That
can be very helpful for complicated (or non obvious) conflicts.  I
still generally look at how to fix them myself (and report them), but
it can save me considerable time in particularly obscure cases.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the security tree with Linus' tree

[Paul Moore]

On Mon, Nov 21, 2022 at 4:56 PM Stephen Rothwell <sfr@rothwell.id.au> wrote:
>
> Hi Paul,
>
> On Mon, 21 Nov 2022 13:47:18 -0500 Paul Moore <paul@paul-moore.com> wrote:
> >
> > I asked this on a previous conflict but never received an answer so
> > I'll ask it one more time: is there a recommended way to notify
> > linux-next of an upcoming conflict?  I generally notice the merge
> > conflict within a few minutes of merging the patches into a -next
> > branch, and fix it shortly afterwards.  I'm happy to provide a
> > heads-up, and a merge example, but I'm not sure what the process is
> > for that, if any.  Or, would you simply prefer to notice it yourself?
> > I'm not bothered either way, I just thought you might appreciate the
> > heads-up.
>
> Sorry about that.  Some maintainers will just send a "heads up" email
> with a suggested resolution patch (but I don't get very many).  That
> can be very helpful for complicated (or non obvious) conflicts.  I
> still generally look at how to fix them myself (and report them), but
> it can save me considerable time in particularly obscure cases.

Okay, I'll make a mental note to send a FYI to the linux-next list
next time I notice a merge conflict.  The real trick will be to see if
I actually manage to remember the next time I see one ;)

-- 
paul-moore.com