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

[Cog Rusty]

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.


> 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.


> 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?


> The patch for changing default file relationships from nodes to users solves many
> issues without introducing excessive permissions related issues.
>
> It's a relatively simple change that doesn't introduce any new tables,
> and only make a minor change to our existing data model.
>
> The real point of this patch is remove all the hackage associated with
> file previews... Have you ever looked at the code that handles
> displaying file previews? Basically today, we have to save the file to
> the session, create a fake menu entry for the file at its final
> destination, and serve the file preview through drupal.  It's kind of a
> pita, resource hog, and in makes file previews dependent on clean urls.
>
> Search through the issue queue for file preview related bug reports.
>
> Look at the crazy code that does file path replacement for node bodies
> during previews.  Look at inline and how it manages to work with
> previews...
>
> It was the most difficult part for me to figure out working with
> drupal's files.  I want to eliminate that pain from every other
> developer's life.
>
> As an aside this patch also centralizes validation handling from
> upload.module to file.inc, so we do gains centralized quota's and file
> extension validation as boon.
>
> Resolving the hanging temp file issues for uploads for this patch also
> resolves the long standing issues with garbage collection in drupal 4.7
> and 5.
>
> The patch has been updated with feedback from unconed(steven wittens)
> and quicksketch(nate huang). I was able to resolve several issues with
> the patch. It's miles from where it was yesterday, and awaiting a fresh
> thrashing and some kind pgsql maven to write a pgsql update path.
>
> http://drupal.org/node/115267
>
> .darrel.
>
>