From: Roberto Sassu <roberto.sassu@huaweicloud.com> To: Mimi Zohar <zohar@linux.ibm.com>, mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, dmitry.kasatkin@gmail.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com Cc: ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-kernel@vger.kernel.org, keescook@chromium.org, nicolas.bouchinet@clip-os.org, Roberto Sassu <roberto.sassu@huawei.com> Subject: Re: [PATCH v7 2/6] ocfs2: Switch to security_inode_init_security() Date: Mon, 20 Feb 2023 13:20:56 +0100 [thread overview] Message-ID: <70d079a7e8b2fa08683b68742a22ba2918765dfc.camel@huaweicloud.com> (raw) In-Reply-To: <1e93d7b299de3b6cf61b5a5c4be91eb47d864ac6.camel@linux.ibm.com> On Mon, 2023-02-20 at 06:08 -0500, Mimi Zohar wrote: > > > > > diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c > > > > > index 95d0611c5fc7..55699c573541 100644 > > > > > @@ -7277,13 +7289,23 @@ int ocfs2_init_security_get(struct inode *inode, > > > > > const struct qstr *qstr, > > > > > struct ocfs2_security_xattr_info *si) > > > > > { > > > > > + int ret; > > > > > + > > > > > /* check whether ocfs2 support feature xattr */ > > > > > if (!ocfs2_supports_xattr(OCFS2_SB(dir->i_sb))) > > > > > return -EOPNOTSUPP; > > > > > - if (si) > > > > > - return security_old_inode_init_security(inode, dir, qstr, > > > > > - &si->name, &si->value, > > > > > - &si->value_len); > > > > > + if (si) { > > > > > + ret = security_inode_init_security(inode, dir, qstr, > > > > > + &ocfs2_initxattrs, si); > > > > > > > > The "if (unlikely(IS_PRIVATE(inode))" test exists in both > > > > security_old_inode_init_security() and security_inode_init_security(), > > > > but return different values. In the former case, it returns > > > > -EOPNOTSUPP. In the latter case, it returns 0. The question is > > > > whether or not we need to be concerned about private inodes on ocfs2. > > > > If private inodes on ocfs2 are possible, then ocsf2_mknod() or > > > > ocfs2_symlink() would fail to create the inode or symlink. > > > > > > Correction, previously when returning -EOPNOTSUPP for private inodes, > > > xattrs would not be wrriten. By returning 0 without setting si->enable > > > to 0, xattrs will be written. > > > > Ok, but if there is a private inode, we would be setting si->enable to > > zero. Should be ok, I guess. > > si->enable is being set to zero, below, but is conditional on !si- > > name. > > This is the last concern, otherwise the patch set looks good. Uhm, if the inode is private, security_inode_init_security() will immediately return. So, the condition !si->name should be always true. Thanks Roberto > > > > > + /* > > > > > + * security_inode_init_security() does not return -EOPNOTSUPP, > > > > > + * we have to check the xattr ourselves. > > > > > + */ > > > > > + if (!ret && !si->name) > > > > > + si->enable = 0; > > > > > + > > > > > + return ret; > > > > > + } > > > > > > > > > > return security_inode_init_security(inode, dir, qstr, > > > > > &ocfs2_initxattrs, NULL);
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu via Ocfs2-devel <ocfs2-devel@oss.oracle.com> To: Mimi Zohar <zohar@linux.ibm.com>, mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, dmitry.kasatkin@gmail.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com Cc: nicolas.bouchinet@clip-os.org, keescook@chromium.org, selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>, reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH v7 2/6] ocfs2: Switch to security_inode_init_security() Date: Mon, 20 Feb 2023 13:20:56 +0100 [thread overview] Message-ID: <70d079a7e8b2fa08683b68742a22ba2918765dfc.camel@huaweicloud.com> (raw) In-Reply-To: <1e93d7b299de3b6cf61b5a5c4be91eb47d864ac6.camel@linux.ibm.com> On Mon, 2023-02-20 at 06:08 -0500, Mimi Zohar wrote: > > > > > diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c > > > > > index 95d0611c5fc7..55699c573541 100644 > > > > > @@ -7277,13 +7289,23 @@ int ocfs2_init_security_get(struct inode *inode, > > > > > const struct qstr *qstr, > > > > > struct ocfs2_security_xattr_info *si) > > > > > { > > > > > + int ret; > > > > > + > > > > > /* check whether ocfs2 support feature xattr */ > > > > > if (!ocfs2_supports_xattr(OCFS2_SB(dir->i_sb))) > > > > > return -EOPNOTSUPP; > > > > > - if (si) > > > > > - return security_old_inode_init_security(inode, dir, qstr, > > > > > - &si->name, &si->value, > > > > > - &si->value_len); > > > > > + if (si) { > > > > > + ret = security_inode_init_security(inode, dir, qstr, > > > > > + &ocfs2_initxattrs, si); > > > > > > > > The "if (unlikely(IS_PRIVATE(inode))" test exists in both > > > > security_old_inode_init_security() and security_inode_init_security(), > > > > but return different values. In the former case, it returns > > > > -EOPNOTSUPP. In the latter case, it returns 0. The question is > > > > whether or not we need to be concerned about private inodes on ocfs2. > > > > If private inodes on ocfs2 are possible, then ocsf2_mknod() or > > > > ocfs2_symlink() would fail to create the inode or symlink. > > > > > > Correction, previously when returning -EOPNOTSUPP for private inodes, > > > xattrs would not be wrriten. By returning 0 without setting si->enable > > > to 0, xattrs will be written. > > > > Ok, but if there is a private inode, we would be setting si->enable to > > zero. Should be ok, I guess. > > si->enable is being set to zero, below, but is conditional on !si- > > name. > > This is the last concern, otherwise the patch set looks good. Uhm, if the inode is private, security_inode_init_security() will immediately return. So, the condition !si->name should be always true. Thanks Roberto > > > > > + /* > > > > > + * security_inode_init_security() does not return -EOPNOTSUPP, > > > > > + * we have to check the xattr ourselves. > > > > > + */ > > > > > + if (!ret && !si->name) > > > > > + si->enable = 0; > > > > > + > > > > > + return ret; > > > > > + } > > > > > > > > > > return security_inode_init_security(inode, dir, qstr, > > > > > &ocfs2_initxattrs, NULL); _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
next prev parent reply other threads:[~2023-02-20 12:21 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-01 10:41 [PATCH v7 0/6] evm: Do HMAC of multiple per LSM xattrs for new inodes Roberto Sassu 2022-12-01 10:41 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` [PATCH v7 1/6] reiserfs: Switch to security_inode_init_security() Roberto Sassu 2022-12-01 10:41 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-02-17 19:47 ` Mimi Zohar 2023-02-17 19:47 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2022-12-01 10:41 ` [Ocfs2-devel] [PATCH v7 2/6] ocfs2: " Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` Roberto Sassu 2023-01-10 8:55 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-01-10 8:55 ` Roberto Sassu 2023-01-12 17:21 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-01-12 17:21 ` Paul Moore 2023-02-08 14:33 ` Roberto Sassu 2023-02-08 14:33 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-02-09 21:05 ` Paul Moore 2023-02-09 21:05 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-02-21 6:45 ` Joseph Qi 2023-02-21 6:45 ` [Ocfs2-devel] " Joseph Qi via Ocfs2-devel 2023-02-21 7:51 ` Roberto Sassu 2023-02-21 7:51 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-02-17 19:51 ` Mimi Zohar 2023-02-17 19:51 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-02-17 21:30 ` Mimi Zohar 2023-02-17 21:30 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-02-20 9:27 ` Roberto Sassu 2023-02-20 9:27 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-02-20 11:08 ` Mimi Zohar 2023-02-20 11:08 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-02-20 12:20 ` Roberto Sassu [this message] 2023-02-20 12:20 ` Roberto Sassu via Ocfs2-devel 2023-02-20 12:40 ` Mimi Zohar 2023-02-20 12:40 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-02-20 8:34 ` Roberto Sassu 2023-02-20 8:34 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` [Ocfs2-devel] [PATCH v7 3/6] security: Remove security_old_inode_init_security() Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` Roberto Sassu 2023-02-19 19:41 ` Mimi Zohar 2023-02-19 19:41 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2022-12-01 10:41 ` [Ocfs2-devel] [PATCH v7 4/6] security: Allow all LSMs to provide xattrs for inode_init_security hook Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` Roberto Sassu 2023-02-20 12:43 ` Mimi Zohar 2023-02-20 12:43 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2022-12-01 10:41 ` [Ocfs2-devel] [PATCH v7 5/6] evm: Align evm_inode_init_security() definition with LSM infrastructure Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` Roberto Sassu 2023-02-19 19:41 ` Mimi Zohar 2023-02-19 19:41 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2022-12-01 10:41 ` [Ocfs2-devel] [PATCH v7 6/6] evm: Support multiple LSMs providing an xattr Roberto Sassu via Ocfs2-devel 2022-12-01 10:41 ` Roberto Sassu 2023-02-19 19:42 ` Mimi Zohar 2023-02-19 19:42 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-02-20 9:49 ` Roberto Sassu 2023-02-20 9:49 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-02-20 10:56 ` Mimi Zohar 2023-02-20 10:56 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-01-12 17:15 ` [Ocfs2-devel] [PATCH v7 0/6] evm: Do HMAC of multiple per LSM xattrs for new inodes Paul Moore via Ocfs2-devel 2023-01-12 17:15 ` Paul Moore 2023-01-13 10:35 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-01-13 10:35 ` Roberto Sassu 2023-03-08 22:16 ` Paul Moore 2023-03-08 22:16 ` Paul Moore 2023-03-08 22:16 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-09 7:53 ` Roberto Sassu via Ocfs2-devel 2023-03-09 7:53 ` Roberto Sassu 2023-03-09 7:53 ` Roberto Sassu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=70d079a7e8b2fa08683b68742a22ba2918765dfc.camel@huaweicloud.com \ --to=roberto.sassu@huaweicloud.com \ --cc=casey@schaufler-ca.com \ --cc=dmitry.kasatkin@gmail.com \ --cc=eparis@parisplace.org \ --cc=jlbec@evilplan.org \ --cc=jmorris@namei.org \ --cc=joseph.qi@linux.alibaba.com \ --cc=keescook@chromium.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mark@fasheh.com \ --cc=nicolas.bouchinet@clip-os.org \ --cc=ocfs2-devel@oss.oracle.com \ --cc=paul@paul-moore.com \ --cc=reiserfs-devel@vger.kernel.org \ --cc=roberto.sassu@huawei.com \ --cc=selinux@vger.kernel.org \ --cc=serge@hallyn.com \ --cc=stephen.smalley.work@gmail.com \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.