[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

Guido Falsi <madpilot at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |Works As Intended
             Status|In Progress                 |Closed

--- Comment #9 from Guido Falsi <madpilot at FreeBSD.org> ---
(In reply to Guido Falsi from comment #8)
> (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.

This is wrong too.

thunar_file_is_writable(file) could return true for files you don't own (think
write bit on a group you are part of), so on which you can't change attributes.
Checking for write permissions to change attributes is unrelated.

I don't know a proper way to cater for a remote file system were you access as
a different user...especially if that user is root and you are not root
locally.

If you find a solution please file a new bug report.

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