Dolphin enforcing permissions - possible to deactivate this?

Help
1

When the user tries to “drag and drop” files or folders into a destination, it appears that Dolphin checks the underlying permissions on the filesystem at the destination.

Normally, this drag and drop operation will result in a menu appearing which asks the user to choose the type of operation (move, copy, link). If Dolphin determines that the user does not have permissions to write to the destination directory, Dolphin will display a red “no” sign, which prevents the user from attempting the operation.

One situation where this becomes an issue is when the underlying filesystem is NFS and the apparent permissions, in the exported filesystem, don’t reflect the local user’s actual permissions on that remote filesystem. An example of this is when the exported filesystem is configured to map all users to root. In this case any local user can write to that remote filesystem with the same level of access as root. Note, in this case I’m talking about NFS mounted on my system without Dolphin’s involvement, not Dolphin connecting to an NFS server directly with the nfs:// scheme.

Dolphin is apparently emulating/duplicating the authorisation checks that exist already in the underlying filesystem layer. There should be an option to turn off this behavior, or at least, to make it only an advisory signal, not an enforcement, i.e. allow the user to choose an operation and attempt that operation even if there is a red “no” sign.

Does anyone with knowledge of Dolphin know if there if there is currently a way to deactivate this feature? I would also be interested in modifying the code and re-compiling from source, if someone can point me to where this is implemented.

I believe this situation pertains to all recent releases of Dolphin.

Thank you.

2

This sounds like a NFS bug?

How would I setup this situation with NFS to test what is going on?
Which OS are you using to create the problem setup?

3

Reading what I wrote in what you quoted, I think I could have worded it differently. None of the file modes are changed. What I meant is that a local user’s “effective permissions” (in the sense of what they can or can’t do) is not reflected in the apparent permissions as seen from the local side. For example, an NFS share can be configured so that a local user is mapped to root, and so can move files into a mode 700 folder despite not owning the folder.

I think this is a pretty common situation in NFS. Sometimes it’s bad, sometimes it doesn’t matter, sometimes it’s desirable. On Linux, you could set up an NFS share with an export line like the following:

/mnt/path 192.168.1.1(rw,all_squash,anonuid=1111,anongid=1111)

This would map all local users’ operations to the given anonuid/anongid. Then you should see that Dolphin will think you do not have access and you won’t be able move files into a folder you do not own. At least, sometimes? See next paragraph.

I’m realizing now after testing this, that this is not happening as consistently as I thought. I can reproduce it in a configuration like the one I gave above, but not consistently. It might be that my theory about why this is happening (Dolphin just emulating the permissions system) is incomplete or not correct. It might be that Dolphin has some other way of making its decision, but I can’t imagine what it would be.

Please tell me and I can work on getting more detailed steps to reproduce this. I’m able to get it to happen consistently on BSD shares, but only sometimes on Linux shares. These mounts are all NFS 4.2. If we can also figure out what information Dolphin is using to determine access, that would help, I think.

4

So you can copy/move files with shell commands?

How do the permissions looks like when displayed by ls?

5

That’s likely a regression from KFileItem: use permissions to determine isWritable and isReadable (!1221) · Merge requests · Frameworks / KIO · GitLab

I have been meaning to revert this for a while.

6

So you can copy/move files with shell commands?

How do the permissions looks like when displayed by ls?

Yes, it works on the CLI, and the restriction just exists on Dolphin. The permissions look normal, the same as they do on the remote system. For example:

drwxr-xr-x.  2 root root     2 Feb  4 17:10 'New Folder'

Since this is an NFS share with all_squash to the UID/GID 0, my local unprivileged user can move files into New Folder.

That’s likely a regression from [ i can’t include a link in my post ]

I have been meaning to revert this for a while.

That would make sense. Thanks for alerting me to that.

What’s weird is that this seems to happen only sometimes on the Linux shares. Most of the shares I have to access are BSD shares and it seems to happen consistently on those. But I haven’t experimented with this thoroughly yet, so I may be missing something.

I might try to re-compile Dolphin after removing the change that was made to kfileitem.cpp, and see if that fixes my issues.