Messages in this thread | | | Subject | Re: 2.6.18-rc4-mm1 | From | Ian Kent <> | Date | Wed, 16 Aug 2006 20:58:28 +0800 |
| |
On Wed, 2006-08-16 at 13:23 +0100, David Howells wrote:
> And saw the following appear in the kernel log around the problem bit for > trash:/usr: > > | ... > | SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts > | audit(1155729189.533:468): avc: denied { read } for pid=6472 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file > | audit(1155729189.557:469): avc: denied { name_bind } for pid=6472 comm="automount" src=716 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket > > Not sure what's going on here. The automounter tried to do bind a socket to a > reserved port perhaps and was denied.
Possibly an RPC ping. That's about the only thing I do that does net connects.
> > | NFS: nfs_update_inode(0:18/2 ct=1 info=0x6) > | NFS: permission(0:18/2), mask=0x1, res=0 > > sys_mkdirat() calls do_path_lookup(), which checks MAY_EXEC on the dir. > > | NFS: permission(0:18/2), mask=0x1, res=0 > > lookup_create() is called. This calls __lookup_hash(), which checks MAY_EXEC > on the dir. > > | -->nfs_lookup(,usr,{200,80,44e3069a}) > > __lookup_hash() then looks up the new dentry with intent to create: > > VARIABLE VALUE > =============================== =============================== > nd->flags LOOKUP_CREATE > nd->intent.open.flags O_EXCL > nd->intent.open.create_mode weird value, even in octal
I'm fairly sure there's a race in autofs for the create case. I've tried to work a solution in the past but haven't been successful yet. In any case autofs should not allow anyone else besides the daemon to do anything in the autofs fs. It's been a while but I think this case leads to a deadlock.
> > This means that nfs_lookup() considers this to be "an exclusive create" of > this node, and dispenses with the LOOKUP RPC call to the server. > > | NFS: lookup(/usr) > | exlusive_create > > Just to confirm that the lookup is skipped. > > | <--nfs_lookup() = 00000000 > > We return the dentry we were given, but don't return an error. The dentry we > were given is left negative (on the assumption it's about to be created), but > does get attached to the directory. > > | NFS: permission(0:18/2), mask=0x3, res=0 > > vfs_mkdir() calls may_create() which checks that the directory has MAY_WRITE > and MAY_EXEC permissions. This firstly calls nfs_permission, which grants > permission. > > | audit(1155729189.605:470): avc: denied { write } for pid=6472 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir > > And secondly calls security_inode_permission() though which SELinux which > _denies_ permission. > > | NFS: dentry_delete(/usr, 0) > > vfs_mkdir() returns -ENOACCES to sys_mkdirat() which releases its hold on the > dentry, but leaves the negative dentry attached to the directory. > > > The negative dentry wouldn't normally be a problem, even though it's attached > to its parent directory... except for the small matter that it's subsequently > listed in a directory read operation.
Surely this dentry should also be unhashed at some point. Wouldn't that be a sensible result of the failed operation? It wouldn't then show up in a listing and the fs should normally be able to deal with these.
Ian
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |