While trying to track down some NFS problems with BTRFS, I kept noticing I was
getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
figure out that it was SELinux that was giving me grief, with the following
denial
type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
Turns out this is because in d_obtain_alias if we can't find an alias we create
one and do all the normal instantiation stuff, but we don't do the
security_d_instantiate.
Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
option there, so in order to deal with the case that a second thread comes in
and finds our new dentry before we get to run security_d_instantiate(), we go
ahead and call it if we find a dentry already. Eric assures me that this is ok
as the code checks to see if the dentry has been initialized already so calling
security_d_instantiate() against the same dentry multiple times is ok. With
this patch I'm no longer getting errant -EACCESS values.
Signed-off-by: Josef Bacik <[email protected]>
---
V1->V2:
-added second security_d_instantiate() call
fs/dcache.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 23702a9..119d489 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
spin_unlock(&tmp->d_lock);
spin_unlock(&dcache_lock);
+ security_d_instantiate(tmp, inode);
return tmp;
out_iput:
+ if (res && !IS_ERR(res))
+ security_d_instantiate(res, inode);
iput(inode);
return res;
}
--
1.6.6.1
On Thu, Nov 18, 2010 at 08:52:55PM -0500, Josef Bacik wrote:
> While trying to track down some NFS problems with BTRFS, I kept noticing I was
> getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> figure out that it was SELinux that was giving me grief, with the following
> denial
>
> type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
>
> Turns out this is because in d_obtain_alias if we can't find an alias we create
> one and do all the normal instantiation stuff, but we don't do the
> security_d_instantiate.
>
> Usually we are protected from getting a hashed dentry that hasn't yet run
> security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> option there, so in order to deal with the case that a second thread comes in
> and finds our new dentry before we get to run security_d_instantiate(), we go
> ahead and call it if we find a dentry already. Eric assures me that this is ok
> as the code checks to see if the dentry has been initialized already so calling
> security_d_instantiate() against the same dentry multiple times is ok. With
> this patch I'm no longer getting errant -EACCESS values.
Thanks, I can't see any reason that wouldn't work.
--b.
>
> Signed-off-by: Josef Bacik <[email protected]>
> ---
> V1->V2:
> -added second security_d_instantiate() call
>
> fs/dcache.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 23702a9..119d489 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
> spin_unlock(&tmp->d_lock);
>
> spin_unlock(&dcache_lock);
> + security_d_instantiate(tmp, inode);
> return tmp;
>
> out_iput:
> + if (res && !IS_ERR(res))
> + security_d_instantiate(res, inode);
> iput(inode);
> return res;
> }
> --
> 1.6.6.1
>
On Fri, Nov 19, 2010 at 05:35:52PM -0500, J. Bruce Fields wrote:
> On Thu, Nov 18, 2010 at 08:52:55PM -0500, Josef Bacik wrote:
> > While trying to track down some NFS problems with BTRFS, I kept noticing I was
> > getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> > figure out that it was SELinux that was giving me grief, with the following
> > denial
> >
> > type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> > comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
> >
> > Turns out this is because in d_obtain_alias if we can't find an alias we create
> > one and do all the normal instantiation stuff, but we don't do the
> > security_d_instantiate.
> >
> > Usually we are protected from getting a hashed dentry that hasn't yet run
> > security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> > option there, so in order to deal with the case that a second thread comes in
> > and finds our new dentry before we get to run security_d_instantiate(), we go
> > ahead and call it if we find a dentry already. Eric assures me that this is ok
> > as the code checks to see if the dentry has been initialized already so calling
> > security_d_instantiate() against the same dentry multiple times is ok. With
> > this patch I'm no longer getting errant -EACCESS values.
>
> Thanks, I can't see any reason that wouldn't work.
(FWIW, I also ran my usual nfs regression tests with this applied. They
don't exercise the problem you were seeing, but maybe it's at least some
sort of sanity check.)
--b.
>
> --b.
>
> >
> > Signed-off-by: Josef Bacik <[email protected]>
> > ---
> > V1->V2:
> > -added second security_d_instantiate() call
> >
> > fs/dcache.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 23702a9..119d489 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
> > spin_unlock(&tmp->d_lock);
> >
> > spin_unlock(&dcache_lock);
> > + security_d_instantiate(tmp, inode);
> > return tmp;
> >
> > out_iput:
> > + if (res && !IS_ERR(res))
> > + security_d_instantiate(res, inode);
> > iput(inode);
> > return res;
> > }
> > --
> > 1.6.6.1
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 20, 2010 at 09:59:45PM -0500, J. Bruce Fields wrote:
> On Fri, Nov 19, 2010 at 05:35:52PM -0500, J. Bruce Fields wrote:
> > On Thu, Nov 18, 2010 at 08:52:55PM -0500, Josef Bacik wrote:
> > > While trying to track down some NFS problems with BTRFS, I kept noticing I was
> > > getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> > > figure out that it was SELinux that was giving me grief, with the following
> > > denial
> > >
> > > type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> > > comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> > > tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
> > >
> > > Turns out this is because in d_obtain_alias if we can't find an alias we create
> > > one and do all the normal instantiation stuff, but we don't do the
> > > security_d_instantiate.
> > >
> > > Usually we are protected from getting a hashed dentry that hasn't yet run
> > > security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> > > option there, so in order to deal with the case that a second thread comes in
> > > and finds our new dentry before we get to run security_d_instantiate(), we go
> > > ahead and call it if we find a dentry already. Eric assures me that this is ok
> > > as the code checks to see if the dentry has been initialized already so calling
> > > security_d_instantiate() against the same dentry multiple times is ok. With
> > > this patch I'm no longer getting errant -EACCESS values.
> >
> > Thanks, I can't see any reason that wouldn't work.
>
> (FWIW, I also ran my usual nfs regression tests with this applied. They
> don't exercise the problem you were seeing, but maybe it's at least some
> sort of sanity check.)
>
Oh I should have mentioned the testing I gave it. With BTRFS I could regularly
reproduce this by doing the following
SERVER
mount /dev/sda1 /mnt/btrfs
btrfs subvol create /mnt/btrfs/foo
cp mutt.tar.gz /mnt/btrfs/foo
CLIENT
mount server:/mnt/btrfs /mnt/test
cd /mnt/test/foo
tar xzvf mutt.tar.gz
cd mutt
ls
SERVER
echo 3 > /proc/sys/vm/drop_caches
CLIENT
ls
and bam I'd get -EACCESS every time. I did this a bunch of times to make sure
it didn't happen anymore plus variations of the above. Thanks,
Josef
On Thu, Nov 18, 2010 at 08:52:55PM -0500, Josef Bacik wrote:
> While trying to track down some NFS problems with BTRFS, I kept noticing I was
> getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> figure out that it was SELinux that was giving me grief, with the following
> denial
>
> type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
>
> Turns out this is because in d_obtain_alias if we can't find an alias we create
> one and do all the normal instantiation stuff, but we don't do the
> security_d_instantiate.
>
> Usually we are protected from getting a hashed dentry that hasn't yet run
> security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> option there, so in order to deal with the case that a second thread comes in
> and finds our new dentry before we get to run security_d_instantiate(), we go
> ahead and call it if we find a dentry already. Eric assures me that this is ok
> as the code checks to see if the dentry has been initialized already so calling
> security_d_instantiate() against the same dentry multiple times is ok. With
> this patch I'm no longer getting errant -EACCESS values.
>
> Signed-off-by: Josef Bacik <[email protected]>
> ---
> V1->V2:
> -added second security_d_instantiate() call
>
> fs/dcache.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 23702a9..119d489 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
> spin_unlock(&tmp->d_lock);
>
> spin_unlock(&dcache_lock);
> + security_d_instantiate(tmp, inode);
> return tmp;
>
> out_iput:
> + if (res && !IS_ERR(res))
> + security_d_instantiate(res, inode);
> iput(inode);
> return res;
> }
> --
> 1.6.6.1
>
Hey Al,
I forgot to cc you directly, is this ok with you, and if it is would you mind
picking it up? Thanks,
Josef
On 11/18/2010 07:52 PM, Josef Bacik wrote:
> While trying to track down some NFS problems with BTRFS, I kept noticing I was
> getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> figure out that it was SELinux that was giving me grief, with the following
> denial
>
> type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
>
> Turns out this is because in d_obtain_alias if we can't find an alias we create
> one and do all the normal instantiation stuff, but we don't do the
> security_d_instantiate.
>
> Usually we are protected from getting a hashed dentry that hasn't yet run
> security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> option there, so in order to deal with the case that a second thread comes in
> and finds our new dentry before we get to run security_d_instantiate(), we go
> ahead and call it if we find a dentry already. Eric assures me that this is ok
> as the code checks to see if the dentry has been initialized already so calling
> security_d_instantiate() against the same dentry multiple times is ok. With
> this patch I'm no longer getting errant -EACCESS values.
>
> Signed-off-by: Josef Bacik <[email protected]>
Thanks, this fixes xfsdump too, see also:
https://bugzilla.redhat.com/show_bug.cgi?id=662344
Bug 662344 - broken SELinux AVCs on XFS partition when running xfsdump
(xfsdump uses the open by handle library from xfsprogs)
-Eric
> ---
> V1->V2:
> -added second security_d_instantiate() call
>
> fs/dcache.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 23702a9..119d489 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
> spin_unlock(&tmp->d_lock);
>
> spin_unlock(&dcache_lock);
> + security_d_instantiate(tmp, inode);
> return tmp;
>
> out_iput:
> + if (res && !IS_ERR(res))
> + security_d_instantiate(res, inode);
> iput(inode);
> return res;
> }
On Thu, 2010-11-18 at 20:52 -0500, Josef Bacik wrote:
> While trying to track down some NFS problems with BTRFS, I kept noticing I was
> getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
> figure out that it was SELinux that was giving me grief, with the following
> denial
>
> type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
> comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
>
> Turns out this is because in d_obtain_alias if we can't find an alias we create
> one and do all the normal instantiation stuff, but we don't do the
> security_d_instantiate.
>
> Usually we are protected from getting a hashed dentry that hasn't yet run
> security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
> option there, so in order to deal with the case that a second thread comes in
> and finds our new dentry before we get to run security_d_instantiate(), we go
> ahead and call it if we find a dentry already. Eric assures me that this is ok
> as the code checks to see if the dentry has been initialized already so calling
> security_d_instantiate() against the same dentry multiple times is ok. With
> this patch I'm no longer getting errant -EACCESS values.
>
> Signed-off-by: Josef Bacik <[email protected]>
Acked-by: Eric Paris <[email protected]>
Al, any chance we can push this along?
-Eric
> ---
> V1->V2:
> -added second security_d_instantiate() call
>
> fs/dcache.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 23702a9..119d489 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1201,9 +1201,12 @@ struct dentry *d_obtain_alias(struct inode *inode)
> spin_unlock(&tmp->d_lock);
>
> spin_unlock(&dcache_lock);
> + security_d_instantiate(tmp, inode);
> return tmp;
>
> out_iput:
> + if (res && !IS_ERR(res))
> + security_d_instantiate(res, inode);
> iput(inode);
> return res;
> }