Date: Tue, 28 Nov 2017 21:11:27 +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-3v9CS6lGzn@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 Guido Falsi <madpilot@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Works As Intended Status|In Progress |Closed --- Comment #9 from Guido Falsi <madpilot@FreeBSD.org> --- (In reply to Guido Falsi from comment #8) > (In reply to rozhuk.im from comment #4) >=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= unix > > with chmod(). >=20 > Looking at the upstream code and checking how UFS works I can now say this > is definitely a wrong assumption. >=20 > you can chmod any file you own, even if it is not writable, otherwise the= re > would be no way to modify permissions on a file with 0444 permissions. > obviously root can change permissions on any file. >=20 > The upstream code, while a little convoluted, checks just for this, which= is > correct for local file systems. >=20 > >=20 > > In my case sshfs mounted to me (simple user), by authorized on remote s= ide > > as root. >=20 > Considering the previous correction this use case is quite peculiar and > difficult to accommodate. >=20 > 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 rem= ote > file system and the actual remote user. >=20 > 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). >=20 > 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 ne= ed > to find some information on why that checks gives a different result. >=20 > 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 (th= ink write bit on a group you are part of), so on which you can't change attribu= tes. 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. --=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-3v9CS6lGzn>