[-next PATCH] security: use octal not symbolic permissions
From: joe@perches.com (Joe Perches)
Date: 2018-06-13 19:30:28
Also in:
linux-integrity, lkml, selinux
On Wed, 2018-06-13 at 12:19 -0400, Paul Moore wrote:
On Wed, Jun 13, 2018 at 12:04 PM, Joe Perches [off-list ref] wrote:quoted
On Wed, 2018-06-13 at 11:49 -0400, Paul Moore wrote:quoted
On Tue, Jun 12, 2018 at 8:29 PM, Joe Perches [off-list ref] wrote:quoted
On Tue, 2018-06-12 at 17:12 -0400, Paul Moore wrote:quoted
Joe, in general I really appreciate the fixes you send, but these patches that cross a lot of subsystem boundaries (this isn't the first one that does this) causes unnecessary conflicts in -next and during the merge window. Could you split your patches up from now on please?Sorry. No. Merge conflicts are inherent in this system.Yes, merge conflicts are inherent in this system when one makes a single change which impacts multiple subsystems, e.g. changing a core kernel function which is called by multiple subsystems. However, that isn't what this patch does, it makes a number of self-contained changes across multiple subsystems; there are no cross-subsystem dependencies in this patch. You are increasing the likelihood of conflicts for no good reason; that is why I'm asking you to split this patch and others like it.No. History shows with high certainty that splitting patches like this across multiple subsystems of a primary subsystem means that the entire patchset is not completely applied.I think that is due more to a lack of effort on the part of the patch author to keep pushing the individual patches.
Nope. Try again. Resistance to change and desire for status quo occurs in many subsystems.
quoted
It's _much_ simpler and provides a generic mechanism to get the entire patch applied to send a single patch to the top level subsystem maintainer.I understand it is simpler for you, but it is more difficult for everyone else.
Not true. It's simply a matter of merge resolution being pushed down where and when necessary. See changes like the additions of the SPDX license tags.
Further, where the LSMs are concerned, there is no "top level subsystem maintainer" anymore. SELinux and AppArmor send pull requests directly to Linus.
MAINTAINERS-SECURITY SUBSYSTEM MAINTAINERS-M: James Morris [off-list ref] MAINTAINERS-M: "Serge E. Hallyn" [off-list ref] MAINTAINERS-L: linux-security-module at vger.kernel.org (suggested Cc:) MAINTAINERS-T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git MAINTAINERS-W: http://kernsec.org/ MAINTAINERS-S: Supported MAINTAINERS:F: security/ MAINTAINERS- If James is not approving or merging security/selinux or security/tomoyo then perhaps the F: entries could be augmented with appropriate X: entries or made specific by using specific entries like: F: security/* F: security/integrity/ F: security/keys/ -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html