[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192

--- Comment #8 from Guido Falsi <madpilot at FreeBSD.org> ---
(In reply to rozhuk.im from comment #4)

> My check is simple: if file writeable than we can write metadata.
> This is good for most cases.
> I dont know how to allow user write data and restrict write metadata in unix
> with chmod().

Looking at the upstream code and checking how UFS works I can now say this is
definitely a wrong assumption.

you can chmod any file you own, even if it is not writable, otherwise there
would be no way to modify permissions on a file with 0444 permissions.
obviously root can change permissions on any file.

The upstream code, while a little convoluted, checks just for this, which is
correct for local file systems.

> 
> In my case sshfs mounted to me (simple user), by authorized on remote side
> as root.

Considering the previous correction this use case is quite peculiar and
difficult to accommodate.

Thunar clearly checks file permissions based on the local user. But the remote
user is different, so it gets wrong conclusions. But I cannot see a way to fix
this except give thunar detailed knowledge of the specific remote file system
and the actual remote user.

Anyway your patch as is cannot be accepted since it is actually wrong for the
UFS semantics. It will work most of the time but fail in important situations
(files with 0444 permissions).

Looks like for some specific sshfs semantics thunar_file_is_writable(file)
returns true and lets you go ahead. But it looks like a coincidence. I need to
find some information on why that checks gives a different result.

The only acceptable option would be to add an || thunar_file_is_writable(file)
right before the "&& !thunar_file_is_trashed (file));" in the last return in
the upstream code. But I still have to evaluate the consequences.

I need to study sshfs a little.

Your suggeestion about adding an ||

-- 
You are receiving this mail because:
You are the assignee for the bug.