Eric Paris <eparis@xxxxxxxxxx> writes: > 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' ? As reported in the URL from above there is a "mount" still running. So clearly mount has not finished. The big question is not why the readlink() blocks. That is totaly expected. The big question is why is the mount hanging. Find that out and you find the bug. Once the mount finishes the readlink will continue. MfG Goswin -- 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
