GNOME Bugzilla – Bug 531598
wrong user/group displayed when using ssh/sftp mounts
Last modified: 2009-03-10 15:07:37 UTC
Please describe the problem: I'm using 2 computers, lets call one 'Desktop' and the other one 'Notebook'. On 'Desktop' I created user 'foo' when installing Ubuntu 8.04 (no other user has been added). On 'Notebook', I created user 'bar' when installing Ubuntu 8.04 and added user 'foo' later (pwd is identical on both systems, uids differ). When I log in 'Notebook' and mount '/home/foo' on 'Desktop' using GNOME's 'Places -> Connect to server' (or similar, I'm using the german version), all files inside '/home/foo' have owner and group 'bar' (although they all belong to 'foo'). It does not matter whether I'm logged in as 'foo' or 'bar' (on 'Notebook'), nautilus always displays owner/group as 'bar'/'bar'! If I connect to 'Dektop' using from bash (i.e. 'ssh -x foo@Desktop') and do a 'ls -l', owner and group are displayed correctly (i.e. 'foo'/'foo'). If I create a file from within Nautilus (from 'Notebook'), owner and group of the newly created file is also 'bar' (no matter which user actually created the file). When doing a 'ls -l' in the shell, user/group is again displayed correctly ('foo'/'foo'). Steps to reproduce: Actual results: Expected results: Does this happen every time? yes Other information:
Expected results: I expect nautilus to display owner and group exactly like the shell does. In the case described above, the correct owner/group would have been 'foo'/'foo' (the 'foo' from 'Desktop' not the one from 'Notebook').
Dear Juergen, thanks for your bug report. This is a gvfs and an OpenSSH issue. Reassigning to gvfs: On the server side ("Desktop") * OpenSSH just sets the UID/GID of the users on the server. They can not be mapped to client UIDs/GIDs * OpenSSH should also set the SSH_FILEXFER_ATTR_OWNERGROUP attributes as specified by the SFTP RFC [1]. On the client side ("Notebook") * gvfs does not interpret SSH_FILEXFER_ATTR_OWNERGROUP. [1] http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt
Thx for your response! I'm not sure if I got the idea. You mean that the issue is specific to the sftp protocol, but not ssh, right? So the SSH_FILEXFER_ATTR_OWNERGROUP is not set on the server and (maybe as a consequence?) not interpreted on the client side. Assuming that this is correct, it still makes me wonder why nautilus always displays the _same_ user/group. If SSH_FILEXFER_ATTR_OWNERGROUP is not interpreted, I would expect that the user that is currently logged in to the client (i.e. the one that established the sftp connection) is displayed as the owner of the files on the server. But it seems that it's always the user that has been created (first) during installation, that is displayed as the owner of the remote files. Except for the files that are owned by root! For them, owner and group are displayed correctly! I wonder about that too...
> You mean that the issue is specific to the sftp protocol, but not ssh, right? Yes. SFTP and remote SSH login are two totally different things. SFTP is a file transfer protocol like FTP, SSH allows remote login like telnet. > I would expect that the user that is currently logged in to the client (i.e. the one that established the sftp connection) is displayed as the owner of the files on the server. The numerical uid/gid of the server are transferred. They can usually not be interpreted by the client in a reasonable way - except if you have a localhost/loopback connection, or distributed UIDs/GIDs (centralized authentication, LDAP or something along those lines). For GnomeVFS, we decided to not transfer UIDs/GIDs at all (#346676). Maybe this should also be done for GVFS.
(In reply to comment #4) > The numerical uid/gid of the server are transferred. They can usually not be > interpreted by the client in a reasonable way - except if you have a > localhost/loopback connection, or distributed UIDs/GIDs (centralized > authentication, LDAP or something along those lines). That makes sense. I first thought that SSH_FILEXFER_ATTR_OWNERGROUP contains uid and gid, because I only ran over the SFTP RFC, but now I see that it contains the strings. And because 'foo' on 'Desktop' has the same uid like 'bar' on 'Notebook', the ownership is always wrong (while it is always correct for root). thx for clarifying this > For GnomeVFS, we decided to not transfer UIDs/GIDs at all (#346676). Maybe this > should also be done for GVFS. Seems like an already fixed gnomevfs bug has been ported to gvfs ;) But, if I got it right, the solution implemented in gnomevfs is not ideal either, because the correct owner/group is not displayed at all. Maybe there is a better solution to this? Regards JK
> Maybe there is a better solution to this? I do not think there is any solution to tell whether the owner/groups are meaningful for the client, unless you connect to localhost. There are to just many scenarios - you could have a centralized OS environment (with an "external" notebook client, or a permanent client), connection through the internet etc.
*** Bug 515906 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > I do not think there is any solution to tell whether the owner/groups are > meaningful for the client, unless you connect to localhost. Actually I'm not talking about mapping user/group to the client (you're right, this may be impossible, especially if no identical user/group exists on the client). I'm just talking about displaying owner/group correctly. And, if this would be possible by interpreting SSH_FILEXFER_ATTR_OWNERGROUP, then imho this should be the preferred solution...
Hi, if become a member recently due to this bug... What's the situation... seems no one has a solution since last post (2008-05-13 08:09 UTC)
I'm not a developer, but to be informed: "Is there some work in progress?"
That's something i would also like to know... :) In my last post... i wrote "Hi, if become a member" LOL... it doesn't have no sense... it shoul be "Hi, i've become a member"
SSH_FILEXFER_ATTR_OWNERGROUP is not implemented in any existing sftp deamon to my knowledge. However, the bug that we were interpreting uid/gid via the local passwd database has now been fixed in nautilus. We now display the uid/gid value, which is right, if not a great UI.