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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
