https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192
Guido Falsi <madpi...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |Works As Intended
Status|In Progress |Closed
--- Comment #9 from Guido Falsi <madpi...@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.
_______________________________________________
freebsd-xfce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xfce
To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
