* Any attempt to create/overwrite symlinks in a partition mounted by fuseext2 causes the fuseext2 process to deadlock, preventing the mounted filesystem from being used at all until the userspace process is killed and the filesystem is remounted.
[Test Case]
* dd if=/dev/zero of=partition bs=1M count=200
* mkfs.ext2 partition
* mkdir mount
* fuseext2 partition mount
* cd mount
* touch test
* ln -s test link - Doesn't complete
* In another shell try to do anything else in the mount directory (ls, touch, rm) - Don't complete
[Regression Potential]
* Since this changes the locking strategy of the code to hold locks less, the main risk is exposing a case where data can be accessed in a non-threadsafe manner, leading to unexpected behaviour.
* The places where the change has been made are at the exit points of the function, and match where similar unlocks are made in other places in the code.
* Since the program at risk is (by design) a userspace program, the risk of kernel data leakage is minimal.
[Other Info]
* I can't actually work out where the upstream code for this project lives, the only upstream I could find is https://github.com/alperakcan/fuse-ext2 but that doesn't have any locking code at all (even in the reentrant branch) so I can't see where this issue came from.
* This issue seems to apply to all versions of fuseext2 in the ubuntu repos (well, at least it's there in trusty, xenial and zesty)
[Impact]
* Any attempt to create/overwrite symlinks in a partition mounted by fuseext2 causes the fuseext2 process to deadlock, preventing the mounted filesystem from being used at all until the userspace process is killed and the filesystem is remounted.
[Test Case]
* dd if=/dev/zero of=partition bs=1M count=200
* mkfs.ext2 partition
* mkdir mount
* fuseext2 partition mount
* cd mount
* touch test
* ln -s test link - Doesn't complete
* In another shell try to do anything else in the mount directory (ls, touch, rm) - Don't complete
[Regression Potential]
* Since this changes the locking strategy of the code to hold locks less, the main risk is exposing a case where data can be accessed in a non-threadsafe manner, leading to unexpected behaviour.
* The places where the change has been made are at the exit points of the function, and match where similar unlocks are made in other places in the code.
* Since the program at risk is (by design) a userspace program, the risk of kernel data leakage is minimal.
[Other Info]
* I can't actually work out where the upstream code for this project lives, the only upstream I could find is https:/ /github. com/alperakcan/ fuse-ext2 but that doesn't have any locking code at all (even in the reentrant branch) so I can't see where this issue came from.
* This issue seems to apply to all versions of fuseext2 in the ubuntu repos (well, at least it's there in trusty, xenial and zesty)