From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org,
haiyangz@microsoft.com, hjanssen@microsoft.com,
"Rafael J. Wysocki" <rjw@sisk.pl>,
James Morris <jmorris@namei.org>,
Jorge Bastos <mysql.jorge@decimal.pt>,
Mark Fasheh <mfasheh@suse.com>, Joel Becker <jlbec@evilplan.org>
Subject: Re: Reiserfs.c bug in 3.2-rc5
Date: Tue, 03 Jan 2012 17:28:36 -0500 [thread overview]
Message-ID: <1325629717.2095.81.camel@falcor> (raw)
In-Reply-To: <CA+55aFwhrk_qYd6Fff8Ezhotta5dxcVYy8g9573uML8V1-=1Sg@mail.gmail.com>
On Tue, 2012-01-03 at 11:17 -0800, Linus Torvalds wrote:
> On Tue, Jan 3, 2012 at 10:45 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >
> > Just clarifying not all of commit fb88c2b, but only the
> > security_old_inode_init_security() hunk.
>
> Is it really sane to have different semantics like that for the
> security[_old]_inode_init_security functions?
No, but unfortunately it seems necessary.
> Look at ocfs2, for example: it does nothing if
> ocfs2_init_security_get() returns 0. That does not sound like the
> correct thing to do, when the fallback is to do ocfs2_init_acl() under
> the lock.
The original code did the same for -EOPNOTSUPP.
7192 ret = ocfs2_init_security_get(inode, dir, qstr, &si);
7193 if (!ret) {
7194 ret = ocfs2_xattr_set(inode, OCFS2_XATTR_INDEX_SECURITY,
7195 si.name, si.value, si.value_len,
7196 XATTR_CREATE);
7197 if (ret) {
7198 mlog_errno(ret);
7199 goto leave;
7200 }
7201 } else if (ret != -EOPNOTSUPP) {
7202 mlog_errno(ret);
7203 goto leave;
7204 }
7205
7206 ret = ocfs2_inode_lock(dir, &dir_bh, 0);
7207 if (ret) {
7208 mlog_errno(ret);
7209 goto leave;
7210 }
7211
7212 ret = ocfs2_init_acl(NULL, inode, dir, NULL, dir_bh, NULL, NULL);
7213 if (ret)
7214 mlog_errno(ret);
7215
> And ocfs2_init_security_get() just calls either
> security_inode_init_security() or security_old_inode_init_security()
> depending on whether ocfs2_security_xattr_info is NULL or not. So I
> really think callers expect the same kind of semantics regardless of
> whether it's the "old" or not version. Which would make sense anyway.
>
> Also, the *documentation* in include/linux/security.h very much says
> that it returns 0 only if @name and @value have been successfully set.
> So my gut feel says that both security_inode_init_security and
> security_old_inode_init_security should return -EOPNOTSUPP (although
> the "new" version doesn't really have "name/value", so maybe returning
> 0 is ok)
The original security_inode_init_security() version queried the LSM for
the security xattr, leaving writing the xattr up to the caller. The
caller changed -EOPNPTSUPP to 0, before returning. The new version
combines the querying and writing the xattr. Like the previous version
it converts the -EOPNOTSUPP to 0, before returning.
reiserfs_security_init() is dependent on
security_old_inode_init_security() to return -EOPNOTSUPP to initialize
some variables and return, but before returning it changes -EOPNOTSUPP
to 0.
Unfortunately this leaves security_old/security_inode_init_security()
needing to return different things.
Mimi
> Anyway, I'd love for (multiple) people who really know the code to
> give me a clean agreement on exactly what the correct patch is.
> Please?
>
> Linus
>
next prev parent reply other threads:[~2012-01-03 22:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-10 23:48 Reiserfs.c bug in 3.2-rc5 Jorge Bastos
2011-12-13 18:07 ` Jan Kara
2011-12-24 11:55 ` Jorge Bastos
2011-12-24 11:55 ` Jorge Bastos
2012-01-02 11:52 ` Jan Kara
2012-01-02 11:52 ` Jan Kara
[not found] ` <005301ccc998$201c9da0$6055d8e0$@jorge@decimal.pt>
2012-01-03 1:08 ` Jan Kara
[not found] ` <000701ccc9fa$74df73f0$5e9e5bd0$@jorge@decimal.pt>
2012-01-03 12:38 ` Jan Kara
2012-01-03 12:38 ` Jan Kara
2012-01-03 15:25 ` Mimi Zohar
2012-01-03 16:48 ` Linus Torvalds
2012-01-03 18:45 ` Mimi Zohar
2012-01-03 19:17 ` Linus Torvalds
2012-01-03 22:28 ` Mimi Zohar [this message]
2012-01-03 23:47 ` James Morris
2012-01-04 0:18 ` Linus Torvalds
2012-01-04 1:02 ` James Morris
2012-01-04 17:15 ` Jan Kara
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=1325629717.2095.81.camel@falcor \
--to=zohar@linux.vnet.ibm.com \
--cc=haiyangz@microsoft.com \
--cc=hjanssen@microsoft.com \
--cc=jack@suse.cz \
--cc=jlbec@evilplan.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=mysql.jorge@decimal.pt \
--cc=reiserfs-devel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
/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: link
Be 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.