[development] files owned by uid, patch review request.

[Darrel O'Pry]

On Sat, 2007-05-05 at 17:25 +0300, Cog Rusty wrote:
> I am listening. I do know that you have put a lot of work into this in
> the past year, I just wanted to make sure that some currently
> available common use cases have been taken into account.
> 
> On 5/5/07, Darrel O'Pry <dopry at thing.net> wrote:
> > On Sat, 2007-05-05 at 06:28 +0300, Cog Rusty wrote:
> > > I wonder what the user-file association would mean for a site which
> > > hires/fires editors and still owns/reuses their files. Or in a site
> > > like drupal.org with patches as attached files?
> >
> > files won't be deleted if users are deleted. for ownership we can assume
> > uid 1 safely if user.uid doesn't exist.
> >
> > > I understand that the orphaned user-files would pile up in a default
> > > user account, but if that is very likely to happen for a lot of files,
> > > then user ownership of files would seem accidental.
> >
> > huh? pile up in a user account? accidental?
> > user_access always returns true when uid=1... that isn't accidental.
> >
> 
> I think I understand what you mean. By "accidental" I meant that if
> (under some common scenarios) too many files are assigned to account
> #1 and the user-owned files are few, then user-ownership of files
> would seem unimportant for basing the system on it. But I can see that
> account #1 can support permissions. I have one more more question
> (below) about whether account #1 is a good way to do that.

What common scenarios? What do you mean too many files assigned to uid
1? 

> > This patch cares very little for where files pile up when a user is
> > deleted.  Right now we don't really care what happens to files if their
> > node gets deleted and they don't, but we also don't have any safe way of
> > sharing files between nodes.
> >
> >
> > > Perhaps files should be able to stand on their own, with options to
> > > associate then with nodes or users?
> >
> > Then who can update, delete, and alter files? How do you control access
> > to files? Drupal's permission system is user based, hence user_access.
> 
> Another questions is (a) who can update, delete, and alter orphaned
> files owned by user #1 (the "super-admin") and (b) whether there can
> be any granularity for securing files "really" owned by user #1.

The answer to your question is undefined. Currently, you cannot update,
delete, or alter files period. Permissions for relating files to nodes
remain unaffected.  Permissions for uploading files are unaffected. 

Yes there can be granular access control to files, but that is a feature
not included in this patch.

> > I've thought about this issue a lot. I've explored it and alternatives
> > quite a bit over the last year. It's the easiest way I've found to
> > implement files in Drupal without depending on nodes. It should be a
> > fairly familiar model, most filesystem systems implement user ownership
> > of files and grant the system super user an all access pass.
> 
> In a Unix-like filesystem, the concept of "user group" permissions
> seems essential for access to files owned by other users or by user
> #1. Does the plan include anything similar? Or isn't this really
> essential?

Groups are fun and important, but are out of scope for this change. I
could imaging a basic administer files permission that would create a
super user group. Much like administer content.