Comment 71 for bug 688576

(In reply to Nate Graham from comment #66)
> Claudius, maybe you can help us resolve this once and for all.
>
> I admit I don't fully understand why problem is still happening for some
> people, but there appears to be a well-understood set of conditions under
> which this *does* work as folks expect.
>
> Is the problem that these conditions are not present by default for all
> newly mounted volumes? Or only some? And the conditions themselves
> unnecessary specific and could be broadened, or do we need to work harder at
> mounting things in a way that satisfies those conditions?

I'd be glad if this could see some progress :)

I just skimmed through the comments again. My current understanding of the cause of the problem is the following:

According to comment #62 and https://code.woboq.org/qt5/kf5/kio/src/ioslaves/trash/trashimpl.cpp.html#1190 there seem to be a check of permissions for the trash folder. This check seems to be there for security concerns. From my understanding it is checked whether only (!) the user can access the files in that folder (meaning access rights of the trash folder set to 0700). This seems to be checked out of security reasons (probably to make sure trashing sensitive files will not expose them suddenly), while it can be debated whether this is necessary.

Mounting with dmask or umask 077 is from my understanding equal to setting the whole drive's permissions to 0700, thus the "security check" passes for drives mounted that way.

So in order to fix this, I guess, we have to possible targets to modify. Either one could probably discuss mounting all drives with those options (which might lead to unwanted side effects), I don't know why the drives are currently mounted the way they are; or one could overthink that "security check". From my POV, I'd vote to pursue the latter option first. Maybe one can come up with some check that is "secure enough".

I'd really like to involve David Faure, if he is still involved into the development or the current maintainer of this project. There has been some discussion going on in this issue about the freedesktop spec which from David's view might be violated by this, but other replied here that this wouldn't be the case.

Also hopefully the other participants of this issue with competence in this region can support.

---

As a side note: I experienced this issue some days ago on a FAT32 USB stick, so that file system seems to also be still affected.