From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965582AbbEMW4J (ORCPT ); Wed, 13 May 2015 18:56:09 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]:44635 "EHLO elasmtp-curtail.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934426AbbEMW4H convert rfc822-to-8bit (ORCPT ); Wed, 13 May 2015 18:56:07 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=deL8v9q833/rCr+DmqQdDT8eBt+pxXnPwdeYrE7h9QXmq9sNn/xgzcldFoe2ceZN; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Antivirus-Status:X-ELNK-Trace:X-Originating-IP; From: "Frank Filz" To: "=?utf-8?Q?'Andreas_Gr=C3=BCnbacher'?=" Cc: , , References: <28e2cd75064ff56bad897b6f69356f4fb15b8128.1429868795.git.agruenba@redhat.com> <0b2401d08da6$dad0d0f0$907272d0$@mindspring.com> <0b2f01d08dbc$d3418940$79c49bc0$@mindspring.com> In-Reply-To: Subject: RE: [RFC v3 20/45] richacl: Automatic Inheritance Date: Wed, 13 May 2015 15:56:04 -0700 Message-ID: <0b3401d08dcf$fe32c070$fa984150$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFhAZmSTBYApv3AaF70HvmdOHyTDgHyZcXjAb4D5GwC6PuA2QCaAz/sAdAKfmmeEYA4YA== Content-Language: en-us X-Antivirus: avast! (VPS 150513-2, 05/13/2015), Outbound message X-Antivirus-Status: Clean X-ELNK-Trace: 136157f01908a8929c7f779228e2f6aeda0071232e20db4d717cf23f34f9ef514318830bb18f9957350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.115.190.27 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Andreas Grünbacher [mailto:andreas.gruenbacher@gmail.com] > Sent: Wednesday, May 13, 2015 2:06 PM > To: Frank Filz > Cc: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux- > nfs@vger.kernel.org > Subject: Re: [RFC v3 20/45] richacl: Automatic Inheritance > > 2015-05-13 22:38 GMT+02:00 Frank Filz : > > So inheritance will happen, but there is also a mode set as part of > > the create that I assume is effectively handled the same as a subsequent > chmod() on the file? > > The effect is similar to a subsequent chmod except that the effective > permissions may be fewer then the create mode: > > * In the traditional POSIX case, the effective permissions are > (create_mode & ~umask). > > * With POSIX ACLs and Richacls, if there are inheritable permissions, > the effective permissions are the intersection of the create mode and > the maximum permissions the inherited acl grants. So if the inherited > acl grants at most rwxr-x---, with a create mode of rw-rw-rw, the > effective permissions end up being rw-r-----. > > > Any chance we could add a system call to do a open/create and pass an > > ACL (and heck, if we go there, why not a system call that allows > > creating with mtime, atime, owner, etc. also...). > > Send patches, but expect them to get killed :) > > > Is there a mode that we could pass that would cause the least amount > > of damage to the inherited ACL? > > Yes, 0777. But the RICHACL_PROTECTED flag will still be set, and that is the > problem in this case. I'm not clear what the RICHACL_PROTECTED flag actually does. It looks like it's only tested in chmod, and then only if the mode matches the mask (at least if I'm understanding the code right). Frank From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Frank Filz" Subject: RE: [RFC v3 20/45] richacl: Automatic Inheritance Date: Wed, 13 May 2015 15:56:04 -0700 Message-ID: <0b3401d08dcf$fe32c070$fa984150$@mindspring.com> References: <28e2cd75064ff56bad897b6f69356f4fb15b8128.1429868795.git.agruenba@redhat.com> <0b2401d08da6$dad0d0f0$907272d0$@mindspring.com> <0b2f01d08dbc$d3418940$79c49bc0$@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , To: =?utf-8?Q?'Andreas_Gr=C3=BCnbacher'?= Return-path: Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]:44635 "EHLO elasmtp-curtail.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934426AbbEMW4H convert rfc822-to-8bit (ORCPT ); Wed, 13 May 2015 18:56:07 -0400 In-Reply-To: Content-Language: en-us Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > -----Original Message----- > From: Andreas Gr=C3=BCnbacher [mailto:andreas.gruenbacher@gmail.com] > Sent: Wednesday, May 13, 2015 2:06 PM > To: Frank Filz > Cc: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; linu= x- > nfs@vger.kernel.org > Subject: Re: [RFC v3 20/45] richacl: Automatic Inheritance >=20 > 2015-05-13 22:38 GMT+02:00 Frank Filz : > > So inheritance will happen, but there is also a mode set as part of > > the create that I assume is effectively handled the same as a subse= quent > chmod() on the file? >=20 > The effect is similar to a subsequent chmod except that the effective > permissions may be fewer then the create mode: >=20 > * In the traditional POSIX case, the effective permissions are > (create_mode & ~umask). >=20 > * With POSIX ACLs and Richacls, if there are inheritable permissions= , > the effective permissions are the intersection of the create mode = and > the maximum permissions the inherited acl grants. So if the inheri= ted > acl grants at most rwxr-x---, with a create mode of rw-rw-rw, the > effective permissions end up being rw-r-----. >=20 > > Any chance we could add a system call to do a open/create and pass = an > > ACL (and heck, if we go there, why not a system call that allows > > creating with mtime, atime, owner, etc. also...). >=20 > Send patches, but expect them to get killed :) >=20 > > Is there a mode that we could pass that would cause the least amoun= t > > of damage to the inherited ACL? >=20 > Yes, 0777. But the RICHACL_PROTECTED flag will still be set, and that= is the > problem in this case. I'm not clear what the RICHACL_PROTECTED flag actually does. It looks l= ike it's only tested in chmod, and then only if the mode matches the ma= sk (at least if I'm understanding the code right). =46rank -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html