Date: Tue, 28 Nov 2017 16:09:37 +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-PNrGLiIuZ1@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 #5 from Guido Falsi <madpilot@FreeBSD.org> --- (In reply to rozhuk.im from comment #4) > IMHO they dont try build without HAVE_GIO_UNIX: GDesktopAppInfo is part of > gio and hey will get undefined struct/type compiler error. > They patch does not work (without mine) - 100%. >=20 > Upstream do many insane and crappy things, I dont want understand why :) First of all a general clarification: I can understand but keep in mind that ports are just that, portings. The development should happen upstream and bugfixes should go there where t= here are developers who know how the existing code works and also usually have better ability to test changes. This kind of changes which diverge from upstream tend to make maintain a po= rt difficult and could also cause regressions which end up being unjustly repo= rted upstream casting shadows on FreeBSD porting methods. I think you understand divergence with upstream should be kept to a minimum. So as a general rule I'm accepting such changes only if they are for very important bugs and have good chance of being merged upstream, or are very FreeBSD specific (which sometimes hinders upstream inclusion). For the GIO part, how do I test in the ports tree with GIO disabled? The po= rt does not have such an option, so it looks like we don't cover this condition either. >=20 > I replace > effective_user_id =3D=3D g_file_info_get_attribute_uint32 (file->info, > G_FILE_ATTRIBUTE_UNIX_UID) > to > thunar_file_is_writable(file) >=20 > All other logic not changed, just refactored to human understanding. >=20 > You can use both checks via ||, like: > return (effective_user_id =3D=3D g_file_info_get_attribute_uint32 (file->= info, > G_FILE_ATTRIBUTE_UNIX_UID) || thunar_file_is_writable(file)) >=20 > May be in some cases there different access levels for file data and > metadata and original code will return TRUE is user is file owner or root. > I dont know what use cases this cover, probably none. >=20 > 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(). As I said while I hear and understand your explanation I have no explanation about the existing code. I'm not refusing your code, and have no specific objection about it. I just need time to understand it properly. In the while if you can get your code included upstream or at least reviewe= d by an upstream developer that would greatly help this request. >=20 > In my case sshfs mounted to me (simple user), by authorized on remote side > as root. Not sure I understand, you mean that you are a plain user on the local mach= ine but authenticated as root on the ssh mount on the remote one? --=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-PNrGLiIuZ1>