Core: Only allow creation of new files/folders on public link shares

[MorrisJobke]

As of today the public upload permission grants full file access (CRUD) to the public link recipient it would be good to have a more fine granular permission system there too.

Use case:

• collection photos of the latest vacation
• I want to send around a link where everybody can drop it's photos
• I don't want that anybody can delete/overwrite existing photos (by accident)

@MTRichards I think this also will be of higher interest once this is noticed, so I raise it early ;)

cc @PVince81 @karlitschek

Followup to #6635

[MorrisJobke]

cc @jancborchardt for UX

[PVince81]

Instead of introducing new kind of permissions that we didn't have before, which would introduce more confusion on the code side and more code paths, I suggest to simply reuse the permissions that we already have:

• can create
• can update
• can delete

These permissions might exist in the backend already but there is no GUI to set them.
The OCS API might already be able to set them, need to try it out, it might already work :smile:

[MorrisJobke]

@PVince81 just said, that the "non-destructive update“ permission (aka no overwrite/delete) could be achieved by only setting the "create" permission and it's most likely already be possible to set this via OCS. It's just a matter of UI that is missing.

[MorrisJobke]

Instead of introducing new kind of permissions that we didn't have before, which would introduce more confusion on the code side and more code paths, I suggest to simply reuse the permissions that we already have:

Totally agree...this was more like a "How I want the UX of the product" and not how it is done technically ;)

[rullzer]

currently the OCS Share API does not support this. As it only takes the public_upload argument into account. It is on my list to converge this, but not very high on the list at the moment.

Since in the db it is just a permission field I can't see any technical limitation why we could not have more fine grain control. But you never know with sharing!

[PVince81]

also note that such permissions will affect federated shares.

Currently when people set "allow editing" for federated shares, the webdav endpoint already allows for such broad operations.

[PVince81]

Setting to backlog for now

[MTRichards]

Fine grain control is desirable for an end user, but it also makes the entire thing more complex to understand.

For a user sharing a link, we should allow these options:

• can create
• can update
• can delete
  Clearly "can read" read only is the default (or why share), and re-share is irrelevant.

Thinking aloud here, the two important permissions are "can change (create + update)" (meaning add folders, add files, rename stuff) and "can delete" (remove stuff).

Between those two, we may have all of the options we need as can read is assumed when you share a document or folder.

Of course, can read could also be an option, but that starts to duplicate files_drop, not necessary at this point.

For discussion: Is it going to far to day that there really is only one option - can change? (create, update and delete)? It is checked or not. Then the containing options from an engineering standpoint are still there, but combined into one option.

[butonic]

how about using the guest app and getting rid of the public upload code path? public links can be emulated by creating an individual guest user.... my 2 cents ...

[jancborchardt]

@butonic Public upload is a really nice/simple and often requested & used functionality. I don't see any UX-related reason to remove it. Or what do you exactly mean?

[butonic]

I only mean the technical solution in the background. I fully acknowledge the use cases for public sharing.

[cdamken]

is it possible to have the same milestone like https://github.com/owncloud/core/issues/6635 ?

@MorrisJobke

00002582
00004149

[cdamken]

@MTRichards @MorrisJobke

is it possible to have the same milestone like #6635 ?

@MorrisJobke

00002582
00004149

[MorrisJobke]

is it possible to have the same milestone like #6635 ?

I don't think, that we will bring this to 9.0 - also 9.1 is pretty full. cc @MTRichards @cmonteroluque

[PVince81]

@rullzer @schiesbn didn't we look into adding CRUDS permissions for fed shares already ? It might jbe a matter of adjusting the UI to also allow setting CRUDS for public links, as internally those permissions are already supported.

[MTRichards]

The plan is to touch the share link work in 9.2 anyway, since we will probable move files_drop over there (write only uploads), so this would also make sense to touch then. 9.0 is out, and 9.1 is way too full right now...so I think 9.2 may be reasonable. As usual, it depends though...on where we are when planning 9.2

[PVince81]

Just to make it clear again: this ticket is about more granular CRUDS permissions for public link shares.

In 9.0, if a public link share already allows read-write permissions, the public link UI already lets you create folders, delete, move, etc.

(just to refresh the memory a bit :smile:)

[rullzer]

Uhm from a technical point of view sure.

From a UX point of view. I'd rather we simply permissions instead of adding more all over the place.

[Pavlin360]

Just updated a server and share link changes totally for our real-world usage...

"External users shares" in version 6 works like this:

Now in version 9:

We want to disable external users to delete or modify files/folders

[PVince81]

Please note that even in the old version it was possible for external users to change files by mounting the link share as federated share "Add to ownCloud". The improvement in 9.0 only brought these actions to the web UI as well.

If you don't want users to modify anything, uncheck "Allow editing" for link shares.

[Pavlin360]

That's ok, but we want to external users can upload files throught web UI like version 6. In version 9 allow more rights by default, and we don't want this

[PVince81]

Not similar to files_drop because people can see each other's files and download it, which is a valid use case.

@pmaier1 @felixboehm

[pmaier1]

IMO all kinds of shares should provide the same permission configuration options which is CRUDS (+ extensions like pdf-only etc. in the future). If this was implemented for public shares we would not even need files_drop and confusion would be reduced by consistency. I think we should not implement small steps like 'files_drop' for instance, rather develop concepts/features that comprise all imaginable use cases or are at least extensible to do so in the future.

[PVince81]

I think this "create only but listing allowed" can be achieved indirectly by anonymous upload: https://github.com/owncloud/core/issues/7747

Basically create two link shares, one for anonymous upload where people drop their stuff in (it's create-only). The second link is a read-only link where people can browse the already uploaded the stuff.

[PVince81]

moving to backlog, needs scheduling

[UKIkarus]

This can be done, and simply requires a few tweaks to accomplish.

The check which says "Can't change permissions for public shared folders" needs to be changed in "owncloud/apps/files_sharing/lib/API/Share200OCS.php" and the file "core/js/sharedialoglinkshareview.js" just needs to be adjusted to give the option WITHOUT delete. (in this instance I altered the original, bit it's simple enough to add another option or tweak it to suit your requirements)

Removing the delete permission (8) results in a permissions level of "7" vs the default "15"

As you can see, permission 7 is set in in the MYSQL shares table and the delete option is now gone 👍