Re: [Phpgroupware-developers] phpWebHosting and ACL

[Giancarlo Susin]

Jason Wies wrote:

>> I don't understand how can a user have access to some files in a 
directory
>>  but not to others, at least in the current VFS model. When VFS  checks
>>  for user privileges in a specific file, it relies on function 
acl->get_rights().
>>  This function doesn't accept a file name as a  parameter; it
>> only gets privileges granted from a group to an user  (and  lately,
>>  to a group too), as stored in table phpgw_acl. This grants to  the
>>  user uniform access to all content of a given directory. So,
>> seems  to me that we still can hide buttons based on directory
>> privileges.  Please correct me if I'm wrong.
>>
>
> The VFS is based on the Unix filesystem model, down to home and .app
>  directories.  As with the Unix model, files in directories can be
> owned by someone different than the owner of the directory.  For
> example, say a site administrator wants to use the /home/Default
> directory to post announcements, and wants these announcements to
> be read-only.  For this installation, the ACL setting in setup is
> set to 'grant', so everyone has full read/write access to
> /home/Default (and everyone is a member of the Default group, of
> course).  So how does the administrator add read-only files to this
>  directory?
>
> 1. Go to /home/Admins 2. Create or upload file (ANNOUNCEMENT, let's
> say) 3. Move ANNOUNCEMENT to /home/Default
>
> When the file was created, it was set to ownership "Admins" because
> that's where it was created.  When it was moved, just as in Unix,
> it retains the ownership.  So in the list of files in
> /home/Default, there will be an ANNOUCEMENT file that is owned by
> Admins and cannot be edited or removed, but can be read (assuming
> read access to Admins was granted to Default).

Ok, it's clear to me now!


> This does bring up the point of explicitly setting different
> permissions for a single file (if the administrator didn't want to
> grant read access to Admins, for example, but just for this one
> file).  I see no reason why this shouldn't be added.  Another
> column in phpgw_vfs and a tweak in acl_check is all it will take in
>  code, but it deserves some thought as to whether we should follow
> the Unix way of Owner-Group-Other, or perhaps do something all our
> own.

Being completely speculative now... Yes, I think it's a good idea to 
allow "file by file" ACL setting in VFS. Maybe this could be done using 
negative numbers in column acl_location in table phpgw_acl. Today, a 
positive number refers to an account_id that grants those rights on all 
files it owns. A negative number would mean those rights apply only to 
the record in table phpgw_vfs whose file_id is equal to acl_location 
without the signal. So we could set different access for files owned by 
the same account, granted to any number of different accounts.

Going further: Since we would need a way to organize the file tree so 
the users could navigate and find all the files they have access, we 
could create something like "local groups" (or "file sharing groups").

A local group would be valid only inside VFS (or phpwebhosting), with 
the purpose of setting file sharing among any groups and/or users. It 
must have a corresponding "home" directory, but at a separate location 
from users and groups' directories, maybe below '/' or '/shares'.

The admin would have a link "Local Groups" in phpWebHosting Admin Page, 
pointing to a page having the current list of local groups and options 
to: create a new one, delete it, rename it or set its ACL settings. The 
ACL setting page would be exactly the same page is shown today to the 
admin to set groups' ACL.

In table phpgw_vfs, a file owned by a local group would be represented 
by a record having a negative owner_id. This owner_id wouldn't point to 
an account, but to another record in phpgw_vfs whose file_id is equal to 
 this number without the signal; this record stores the "home" 
directory of the local group.

Trying to present an example...

table phpgw_accounts (partial):
+------------+-------------+
| account_id | account_lid |
+------------+-------------+
|          1 | Default     |
|          2 | Admins      |
|          3 | demo        |
|          4 | demo2       |

table phpgw_vfs (partial):
+---------+----------+-----------------------+---------------+
| file_id | owner_id | directory             | name          |
+---------+----------+-----------------------+---------------+
|       1 |        3 | /home                 | demo          |
|       2 |        4 | /home                 | demo2         |
|       3 |        1 | /home                 | Default       |
|       4 |        2 | /home                 | Admins        |
|       5 |       -5 | /shares               | Announcements |
|       6 |       -5 | /shares/Announcements | urgent.html   |

table phpgw_acl:
+---------------+--------------+-------------+------------+
| acl_appname   | acl_location | acl_account | acl_rights |
+---------------+--------------+-------------+------------+
| phpwebhosting | run          |           1 |          1 |
| phpwebhosting | run          |           2 |          1 |
| phpwebhosting | -5           |           1 |          1 |
| phpwebhosting | -5           |           2 |         15 |
+---------------+--------------+-------------+------------+

In this case, Annoucements is a local group who shares directory 
/shares/Announcements and file urgent.html with groups Admins (all 
rights) and Default (read only). This doesn't affect each one's group 
directories in any way.

Just some thoughts, don't know how much work to get this done...

Giancarlo