Ticket #78 (new enhancement)

Opened 4 years ago

Last modified 3 years ago

Respect permissions when viewing through the web application

Reported by: mlandauer Assigned to: kenji
Priority: major Milestone:
Component: GUI Version:
Keywords: Cc:

Description

By default only show things which are viewable by a user like "nobody". Make the user login with their own normal login to see files that are owned by them but not viewable by other people.

Change History

02/16/07 10:55:45 changed by bruno

  • milestone set to Uncommited Work.

Assigning to the right milestone.

03/20/07 16:00:07 changed by julians

Here are a few thoughts on part 2 of this ticket (allowing users to login.)

This would ideally follow whatever permission model is used by the respective file system(s). For starters, let's focus on UNIX permissions (rwxrwxrwx style) - access lists as used in Windows or SELinux complicate matters even more.

Firstly, as far as listing files is concerned, this would only need to pay attention to the directory permissions (in UNIX, a file can be listed by any user regardless of its permissions as long as the user can access the directory.)

This situation is slightly complicated once we have plug-ins that put meta data relating to the contents of a file into the database; in this situation, users without the necessary permissions might glean information from doing filtering. For instance if a plugin would create a keyword index for each file and filtering would not pay attention to permissions, a user could learn something about the contents of a file he would normally not have access to by trying to filter for different keywords and see whether the file shows up in the results.

But let's ignore that for now as the meta data gathered by the planned plugins can hardly be considered sensitive (so far, file type and image dimensions) unless the environment Earth is used in has very high security requirements.

So let's focus on whether the user in question can list a given directory.

In UNIX, a directory can be listed by a given user if both of the following are true:

  • The user has "read" permission for the directory in question, that is: the directory is world-readable, or user-readable and owned by the user, or group-readable and owned by a group the user is a member of.
  • The user has "execute" permission for every parent directory of the directory in question, that is: each parent directory is world-executable, user-executable and owned by the user, or group-executable and owned by a group the user is member of.

The fact that it's not enough to look at only a directory's permissions and ownership to see whether that directory can be listed poses a significant problem in terms of database query performance since it is (to my knowledge) not possible to design a single SQL query (even one with sub-selects) that could test for all the conditions recursively.

Post-filtering search results in the web application is not really an option as it would break our use of the OFFSET and LIMIT SQL clauses for pagination and our use of SUM and COUNT to determine directory sizes and file counts recursively.

That said, I can see the following solutions to this problem from here:

  • Use stored procedures to test recursively for the conditions. This should alleviate the performance issue somewhat but will probably still incur a major performance hit. In addition, stored procedures are not very portable and thus make it harder to allow Earth to use databases other than PostgreSQL.
  • At directory insertion/update time, determine a list of users that can read each directory. Directory that are world-readable (and all their parents world-executable) - the most common case - should be handled specially to keep database size in check. The big drawback of this approach is that it is not sensitive to changes in a user's group membership. The permission information would need to be rebuilt every time a user joins or leaves a group. In addition, the permission information would need to be rebuilt for all subdirectories of a directory when the permissions or ownership on that directory changes.

Both solutions are unsatisfactory. Unless someone else can come up with a robust way of solving this issue while not putting too big of a dent into query performance, I would suggest to simplify this issue for now by excluding certain directories from indexing, for instance any directory that has non-world-executable parents unless it is only user-readable and its non-world-executable parents are user-executable and owned by the same user. This exception would still allow for indexing locked down home directories while simplifying the model to "each directory is either world readable or readable by a particular user".

Obviously, all of this needs more thought, but I hope that this comment provides a good starting point for discussing where to take this from here.

10/18/07 16:06:13 changed by matthewl

  • milestone deleted.

Milestone Uncommited Work deleted