Date: Tue, 28 Nov 2017 20:59:18 +0000 From: bugzilla-noreply@freebsd.org To: xfce@FreeBSD.org Subject: [Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs Message-ID: <bug-202192-28711-JWCmDF43lS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-202192-28711@https.bugs.freebsd.org/bugzilla/> References: <bug-202192-28711@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202192 --- Comment #8 from Guido Falsi <madpilot@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 u= nix > 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. >=20 > 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 rem= ote 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 syst= em and the actual remote user. Anyway your patch as is cannot be accepted since it is actually wrong for t= he UFS semantics. It will work most of the time but fail in important situatio= ns (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(fi= le) 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 || --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202192-28711-JWCmDF43lS>