Bug 516594 – sys-fs/fatsort: uses RESTRICT=userpriv

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Michał Górny 2014-07-07 07:39:41 UTC]

Why does it need RESTRICT=userpriv? Looks like it's going to attempt to do something nasty during the tests...

Please keep this bug open as long as the ebuild has RESTRICT=userpriv.

[Comment 1 Daniel Pielmeier 2014-07-09 08:47:39 UTC]

As fatsort operates on fat file systems, its tests also need to work with the file system.

The tests are currently structured like this:
create a file system
populate it with files and directories
mess with the filesystem
run fatsort
check if fatsorts output is the expected one

What does not work with userpriv is the mount and umount commands as those can not be performed as a regular user.

[Comment 2 Michał Górny 2014-07-09 13:07:22 UTC]

Oh, ok. Do I assume correctly that it uses a loop-mount? Anyway, it seems that this one can be fixed only with CAP_SYS_ADMIN.

Of course, upstream could support one of the userspace solutions for writing into VFAT. But I guess there's no point in wasting time for that.

[Comment 3 Daniel Pielmeier 2014-07-09 17:05:35 UTC]

(In reply to Michał Górny from comment #2)
> Oh, ok. Do I assume correctly that it uses a loop-mount? Anyway, it seems
> that this one can be fixed only with CAP_SYS_ADMIN.
> 
> Of course, upstream could support one of the userspace solutions for writing
> into VFAT. But I guess there's no point in wasting time for that.

Yes it uses a loop mount.

Are there other possible alternatives in addition to mtools which you are aware of. I could suggest upstream to use one of those.

[Comment 4 Michał Górny 2014-07-09 18:18:52 UTC]

(In reply to Daniel Pielmeier from comment #3)
> (In reply to Michał Górny from comment #2)
> > Oh, ok. Do I assume correctly that it uses a loop-mount? Anyway, it seems
> > that this one can be fixed only with CAP_SYS_ADMIN.
> > 
> > Of course, upstream could support one of the userspace solutions for writing
> > into VFAT. But I guess there's no point in wasting time for that.
> 
> Yes it uses a loop mount.
> 
> Are there other possible alternatives in addition to mtools which you are
> aware of. I could suggest upstream to use one of those.

Well, I can think of two alternatives right now:

1. one of the FUSE filesystemd -- requires FUSE support in kernel, still stateful,

2. mtools -- full userspace, can be expressed in DEPEND.

[Comment 5 Daniel Pielmeier 2017-09-04 15:44:33 UTC]

With the latest version bump to 1.4.2 I have disabled the tests completely as it gets harder and harder for me to maintain them.