On Fri, 2009-11-13 at 07:58 +0100, Miklos Szeredi wrote: > On Thu, 12 Nov 2009, Josef Bacik wrote: > > Hello, > > > > There is a problem where if you have certain audit rules in place > > you can hang on mount of a fuse filesystem. If you follow the > > instructions here > > > > https://bugzilla.redhat.com/show_bug.cgi?id=493565#c44 > > > > it is easy to reproduce. The problem is after the mount request > > gets sent, the mounting process gets stuck going off to read xattrs > > to satisfy audit's curiosity, and then we get stuck because that > > tries to get a request, but can't because the connection is blocked. > > This patch fixes the problem, but I'm not entirely sold on it, it's > > rather quick and dirty. Basically if we haven't finished the > > initialization of the connection just return -EAGAIN. This fixes > > the problem, audit seems to be ok with getting that as an error. > > Why not rather fix audit not to do this? > > We had a similar problem in SMACK in the past, and my reasoning at the > time should apply here as well: calling into filesystem code before > it's fully initialized (i.e. mount is finished) is not guaranteed to > work for *any* filesystem. Fuse will hang, others may just see silent > memory corruption. > > So NACK, unless there's some fundamental reason why audit can't be > properly fixed. I don't buy the argument that audit did anything wrong. mount S ffff88001f86bd28 0 4126 4120 0x00000080 mount S ffff88001f86bd28 0 4126 4120 0x00000080 ffff88001f86bc38 0000000000000086 0000000000000011 ffff88001f86bc08 0000000000000700 0000000000000000 0000000000000013 ffffffff815884cd ffff8800377532c8 000000000000f8e0 ffff8800377532c8 0000000000015600 Call Trace: [<ffffffffa01bec71>] fuse_get_req+0xb8/0x15b [fuse] [<ffffffffa01bf359>] fuse_getxattr+0x58/0x14f [fuse] [<ffffffff811b9ea2>] get_vfs_caps_from_disk+0x52/0xcd [<ffffffff81093809>] audit_copy_inode+0x83/0xb1 [<ffffffff81093d4f>] __audit_inode+0x1ee/0x1fd [<ffffffff81104789>] audit_inode+0x28/0x2a [<ffffffff811066b4>] do_path_lookup+0x63/0x8b [<ffffffff81107c9c>] user_path_at+0x56/0x93 [<ffffffff810ffaf0>] sys_readlinkat+0x2d/0x91 [<ffffffff810ffb6f>] sys_readlink+0x1b/0x1d [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b Userspace called readlink() and the audit system (after the vfs worked out the path) needs to collect any fcaps. I don't agree, but would be willing to accept your argument that things like SELinux and SMACK can't make filesystem calls during the mount(2) operation but clearly this isn't done during a mount call, it's done by calling readlink. The mount syscall is finished and we still can't use the FS? How is Audit supposed to be 'fixed' ? -- 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
