[Unionfs] Re: 2.6.26-rc4: smack and unionfs deadlock

Casey Schaufler casey at schaufler-ca.com
Sat Jun 7 17:47:04 EDT 2008


Luiz Fernando N. Capitulino wrote:
> Em Thu, 05 Jun 2008 22:11:19 -0700
> Casey Schaufler <casey at schaufler-ca.com> escreveu:
>
> | Casey Schaufler wrote:
> | > Luiz Fernando N. Capitulino wrote:
> | >>  Hi Casey,
> | >>
> | >>  I've got another deadlock which only happens when CONFIG_SMACK is
> | >> enabled, but this time it happens with unionfs and I don't know
> | >> which of the two is causing the problem.
> | >>
> | >>   
> | >
> | > I need a little education. unionfs has a lock on its superblock,
> | > which appears to be where we're getting hung up. What condition
> | > is this lock for? It would seem that a getxattr would be pretty
> | > safe without having the superblock locked, but no one is going
> | > to accuse me of being excessively skilled at locking issues.
> | > I'm going to see what goes wrong without that lock, and if removing
> | > it takes care of the problem. There may be more than one dragon
> | > in these waters.
> | >
> | > Thank you.
> | >
> | OK. The sb associated with unionfs has a magic number of 0,
> | which implies you haven't set it. Is this intentional, or
> | do you just figure no one cares, or should care?
> | 
> | I can relieve the hang by having the Smack code treat
> | unionfs (actually the "0" file system) as one of the
> | special cases. The "real" file shows the correct smack
> | value, the unionfs shows "*", and access is correctly
> | controlled in either case. I'm still looking to see what
> | to do better, and I'd still like to understand the locking
> | strategy better.
>
>  Casey, I'm afraid that only Erez (unionfs maintainer)
> can answer you here but it seems that he's away or
> something.
>
>  His last message on unionfs ML dates about one month
> back.
>
>  :(
Ok. Here's a temporary patch that makes everything except looking at
the Smack label work properly. I haven't signed it off because I
don't think it's ready for prime-time, but if the problem is holding
anyone up it will allow them to proceed.

diff -uprN -X linux-2.6.25-g0602-base/Documentation/dontdiff linux-2.6.25-g0602-base/security/smack/smack_lsm.c linux-2.6.25-g0602/security/smack/smack_lsm.c
--- linux-2.6.25-g0602-base/security/smack/smack_lsm.c	2008-06-04 18:18:44.000000000 -0700
+++ linux-2.6.25-g0602/security/smack/smack_lsm.c	2008-06-06 18:15:42.000000000 -0700
@@ -1874,6 +1874,17 @@ static void smack_d_instantiate(struct d
 
 	sbp = inode->i_sb;
 	sbsp = sbp->s_security;
+
+	/*
+	 * If the superblock isn't initialized someone
+	 * has cobbled together a filesystem that never
+	 * got mounted.
+	 */
+	if (sbsp->smk_initialized == 0) {
+		isp->smk_inode = smack_known_star.smk_known;
+		isp->smk_flags |= SMK_INODE_INSTANT;
+		goto unlockandout;
+	}
 	/*
 	 * We're going to use the superblock default label
 	 * if there's no label on the file.
@@ -1913,6 +1924,18 @@ static void smack_d_instantiate(struct d
 		 */
 		final = smack_known_star.smk_known;
 		break;
+	case 0:
+	case UNIONFS_SUPER_MAGIC:
+		/*
+		 * It seems that unionfs uses a fake superblock
+		 * and doesn't set the magic number therein.
+		 * Assume that an unset magic number is unionfs.
+		 *
+		 * Let the real filesystem inodes provide the
+		 * Smack label on access checks.
+		 */
+		final = smack_known_star.smk_known;
+		break;
 	case DEVPTS_SUPER_MAGIC:
 		/*
 		 * devpts seems content with the label of the task.



-- 

----------------------

Casey Schaufler
casey at schaufler-ca.com
650.906.1780




More information about the unionfs mailing list