Re: remade patches for libnautilus-private/nautilus-file.c

[Alexander Larsson <alexl redhat com>]

On Mon, 2005-03-21 at 01:37 +0100, edoardo wrote:
> hi gals and dudes : )
> 
> i decided to remake the patch to nautilus-file.c into two different 
> patches. this is the first one, including trivial easy changes to the 
> file. the second one will be a lot more complex, and will deal with using 
> _ACCESS instead of uid and gid checks.
> 
> hope this works : )

The corresponding gnome-vfs changes are not in yet, but once they are we
could add this as a first step.

However:

-       /* FIXME bugzilla.gnome.org 40644: 
-        * Can we trust the uid in the file info? Might
-        * there be garbage there? What will it do for non-local files?
-        */

The main part of that comment can be removed. However, it still has a
point. All these checks are essentially wrong for non-local files. 

Say your user is uid 501 on you machine, and some ftp site on the other
side of the world says that a file is owned by uid 501. A couple of
questions immediately pop up:

* Does it really matter what your local user id/username is? The
important thing is if the file is owned *by the user you logged into the
ftp server as* (which might or might not have the same name or uid as
your local user).
* Even if you logged in as yourself (same username) on the ftp server,
the system could be using a different uid for this user. (if its on some
other network for instance.)
* The ftp server might not be running a unix system, so its access
rights scheme might be different than the standard unix behaviour.
However, it generates "some sort of uid/permisssions" for the file that
is "mostly like" what the real permissions are, but not quite. Believing
these can result in the wrong behaviour.

Furthermore, even for the unix filesystem there are filesystems that
don't exactly correspond to the traditional unix permissions system. For
instance, many new filesystems has ACLs, which adds additional
permission information to files. So, looking at the uid+permissions it
seems like we should be allowed to read the file, but when if you try
you'll fail, because of an extra ACL. Thus, the whole function is
unreliable in some cases.

This is why i was talking about the ACCESS stuff in my earlier mail. In
the case of ACLs, if you use the access(2) syscall to figure out if
you're allowed to access the file or not it will work even in the case
of ACLs. And the abstraction of access(2) in gnome-vfs (the _ACCESS
stuff) allows the various backends (such as ftp) to actually implement
an access rights checking system that works for that particular type of
backend.

So, while this patch fixes some minor cleanness details the main problem
is still there. Of course, the real solution is quite a bit harder to
implement. We don't want to call access() for each file when we're
getting the file information, as that can be quite slow. Instead we'd
introduce a new NautilusFileAttributes for NautilusFiles that contains
the permissions information from an async get_file_info() call that
passes GNOME_VFS_FILE_INFO_GET_ACCESS_RIGHTS in the options. 

Then we need to make the functions like nautilus_file_can_read() just
look at GNOME_VFS_PERM_ACCESS_READABLE (if the access rights are loaded
and the access field was valid). We also need to update all callers of
functions like these so that they make sure that the access rights
attribute on the NautilusFile is loaded before calling it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a genetically engineered shark-wrestling inventor who knows the secret of 
the alien invasion. She's a transdimensional bisexual bounty hunter from a 
family of eight older brothers. They fight crime!