GNOME Bugzilla – Bug 558679
ssh backend does bogus permission mapping
Last modified: 2009-05-02 15:43:11 UTC
[ Forwarded from http://bugs.debian.org/503641 from Matthias Bläsing ] the permission mapping of the gvfs ssh backend looks bogus. This is the listing of the directory on the server: mblaesing@XXXXX:/var/www/main/administrator/components/com_displaystatementcomponent$ ls -lh insgesamt 20K -rw-rw-r-- 1 mblaesing mblaesing 650 26. Okt 23:02 displaystatementcomponent.php -rw-rw-r-- 1 www-data www-data 45 26. Okt 21:12 index.html -rw-rw-r-- 1 www-data www-data 364 26. Okt 21:12 install.sql -rw-rw-r-- 1 mblaesing mblaesing 1,1K 26. Okt 21:56 install.xml -rw-rw-r-- 1 www-data www-data 45 26. Okt 21:12 uninstall.sql mblaesing@XXXXX:/var/www/main/administrator/components/com_displaystatementcomponent$ And (here especially important): uid=1000(mblaesing) gid=1000(mblaesing) Gruppen=4(adm),33(www-data),1000(mblaesing),1002(sshuser),1003(beamerthemefsc),1004(sitzungsprotokollng),1006(filevault),1007(webalizer),1008(gammusync) As you can see - I'm member of the www-data group - so I expect read-write access on any file in the listing. No compare this: mblaesing@enterprise:~/.gvfs/SFTP auf XXXXX/var/www/main/administrator/components$ ls -lh com_displaystatementcomponent insgesamt 1,5K -rw------- 1 mblaesing mblaesing 650 26. Okt 23:02 displaystatementcomponent.php -r-------- 1 mblaesing mblaesing 45 26. Okt 21:12 index.html -r-------- 1 mblaesing mblaesing 364 26. Okt 21:12 install.sql -rw------- 1 mblaesing mblaesing 1,1K 26. Okt 21:56 install.xml -r-------- 1 mblaesing mblaesing 45 26. Okt 21:12 uninstall.sql mblaesing@enterprise:~/.gvfs/SFTP auf XXXXX/var/www/main/administrator/components$ The same happens for the directory permissions - so basicly nautilus is useless on the whole tree, as I can only sensibly access files/dirs, that belong to me. I thing the ssh method should map the permissions to what the user on the server machine would expect. In my case I would expect 0600 for each file.
There is no way gvfs can know what gid 1000 on the server means, or that the user you're logged in as is part of that group. The protocol has no way to know this. All the protocol tells us is the uid/gid of the file and the permissions based on those. We sort of guess out uid/gid by looking at the ownership of $cwd on login, which is the only thing we can use wrt guessing the actual permission rights. So, there is little we can do here. If you know any way to do better, please re-open.
Two approaches come to mind: - instead of trying to map the server-side permissions on the client, set them to something very permissive. When an operation occurs on the client, attempt it on the server and if it fails, return -ENOPERM on the client. - use the current cwd method to determine the UID of the user, and then attempt to fetch /etc/passwd and /etc/group. If that succeeds, that should provide gvfs with enough information to perform a smarter mapping (unless some sort of external authorization is being used on the server?). Obviously they both have their caveats, but I think it would better than what we have now, at least if this behaviour was configurable. Cheers!