[Pig Wiki] Update of "Howl/HowlAuthorizationProposal" by AlanGates

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Pig Wiki" for change notification.

The "Howl/HowlAuthorizationProposal" page has been changed by AlanGates.
http://wiki.apache.org/pig/Howl/HowlAuthorizationProposal?action=diff&rev1=1&rev2=2

--------------------------------------------------

  
  If  db.tablename syntax is supported (I believe it may not be supported in the initial commit), then create db.tablename will need to check that the user has write permission on db directory.
  
+ == Comments ==
+ This model is built around using group permissions to share table access.  A few implementation notes concerning this.
+  1. Conceptually it is possible for someone to create a table in directory {{{/x/y/z}}} where they own `z` but not `x` or `y`.  If the owner of `x` or `y` then changes their permissions so that the table creator (or others in the group the table is owned by) cannot access direcotry `z` then the table creator (or others in the group) will not be able to access the table.  For tables under the default directory, this will not be an issue.  For tables outside this directory, it will be the responsibility of the user not to put their files in a place where this is likely to happen (note that this is true regardless of the authorization model we adopt).  
+  1. What permissions will the top level warehouse directory have?  We could choose to let them have 777, so that anyone can create tables there.  We could also define a `howl` group and declare that all users who wish to use Howl must use be in this group.  The top level directory could then be 770, locking out any users who were not authorized to use Howl.  Given that we expect in many installation all or most all data to be managed by Howl, it is not clear how useful this would be.
+  1. There is a security hole in who can drop tables.  Since the ability to delete a file is based on write permission in the directory that contains it and not write permission on the file itself, once a table is created but before it has any files anyone with permission to create tables can drop that table.  (It is no longer a problem once files or directories have been created in the table directory, because removing those will require write permission on the table directory.)  In the case of the default warehouse that means everyone has permission to drop empty tables.  In the case of other databases it means everyone in the database group has these permissions.  One way around that would be to create an empty file under the table directory, `_empty`.
+  1. The above vulnerability also applies to database directories and could be resolved in the same way.
+  1. In the POSIX permissions model the narrowist applicable category is used in testing whether a specific user has access to a file.  Thus if the owner of a file does not have permission to read the file, but he is in a group that does, he still will not be able to read the file.  To avoid strange side affects of this I propose that it be an error if the owner has less permission than the group.  So `rwxr-x---` would be accepted, but `r-xrwx---` would return an error.
+  1. Execute bits give a user permission to open a directory, which is required to open files for either reading or writing.  Thus for all users classes it should be an error for the read or write bit to be set but not the execute bit.  Thus `r-x`, `-wx`, `rwx` would all be valid combinations, but `r--`, `-w-`, and `rw-` would be generate errors.
+  1. Do we ever want to allow a user to set a table as world writable?
+  
+