On Fri, May 27, 2016 at 08:09:09PM +0900, Seung-Woo Kim wrote:
> After commit, "b968091 security_d_instantiate(): move to the point prior to attaching dentry to inode", booting on system with
> systemd and security smack, following kernel panic occurs.
/*
* If this is a new directory and the label was
* transmuted when the inode was initialized
* set the transmute attribute on the directory
* and mark the inode.
*
* If there is a transmute attribute on the
* directory mark the inode.
*/
if (isp->smk_flags & SMK_INODE_CHANGED) {
isp->smk_flags &= ~SMK_INODE_CHANGED;
rc = inode->i_op->setxattr(dp,
XATTR_NAME_SMACKTRANSMUTE,
TRANS_TRUE, TRANS_TRUE_SIZE,
0);
Damnation ;-/ That change (separating inode and dentry arguments of
->getxattr() so that security_d_instantiate() could be called before dentry
is hashed or attached to inode) had been discussed back in early March and
reaction of Casey back then had been basically "I believe that smack can
live with that, will verify that in about a week". With no followup
objections - neither immediate, nor in a week. As the matter of fact,
your posting is the first time anyone has reported stepping into that problem.
And that change had been present in linux-next since the beginning of May ;-/
Sigh...
> It works fine if reverting the commit, "b968091 security_d_instantiate(): move to the point prior to attaching dentry to inode", for
> d_instantiate() like following.
Can't be reverted in mainline. Not without shitloads of other stuff.
There is a fairly straightforward way to handle that - do to ->setxattr()
what we'd already done to ->getxattr(). See vfs.git#smack-fix. Warning:
it's only build-tested. I'm going to have it go through LTP and xfstests
shortly; _please_ check if it works on your setup, because I've no idea
how to put together a testing setup for smack.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
