linux-kernel - Re: [-next PATCH] security: use octal not symbolic permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Jun 2018 17:29:14 -0700
From:   Joe Perches <joe@...ches.com>
To:     Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        John Johansen <john.johansen@...onical.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Eric Paris <eparis@...isplace.org>,
        Kentaro Takeda <takedakn@...data.co.jp>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
        selinux@...ho.nsa.gov
Subject: Re: [-next PATCH] security: use octal not symbolic permissions

On Tue, 2018-06-12 at 17:12 -0400, Paul Moore wrote:
> On Tue, Jun 12, 2018 at 4:32 PM, James Morris <jmorris@...ei.org> wrote:
> > On Mon, 11 Jun 2018, Casey Schaufler wrote:
> > 
> > > If you want to break this up by security module I would take
> > > the Smack part as soon as James does the tree update. If James
> > > wants to take the whole thing at once you can add my:
> > > 
> > > Acked-by: Casey Schaufler <casey@...aufler-ca.com>
> > > 
> > > for the Smack changes.
> > 
> > It's probably simplest for me to take them as one patch.
> 
> I would prefer if the SELinux changes were split into a separate
> patch.  I'm guessing John would probably want the same for the
> AppArmor patches, but take his work for it, not mine.
> 
> 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.

There is just no good way to do this as sending a set
of per subsystem patches guarantees partial application
of the entire set.

The nominal best way is for a script to be run and
applied at the top level rather than sending a patch
at all.

If you prefer, each sub-subsystem maintainer, at
whatever granularity desired, could apply the patch
to the appropriate subsystem by using
"git am --include=<subsystem_path>".

cheers, Joe