Sharing single files within a shared folder resulting in sharing link being whole folder sharing link

[stp-ip]

When I want to share a single file from within a shared folder it's not possible.

The provided link is the shared folder link and therefore after sharing a folder single files can't be shared.

For me that's just wrong an therefore a bug.

Current stable. Haven't had time to try in master, but it's at least a bug in stable.

[georgehrke]

I think that's intended.

ping @MTGap

[jancborchardt]

Doesn’t sound like it’s intended or a good choice. @stp-ip is right in finding that behavior strange.

@DeepDiver1975 @MTGap your statement?

[RandolfCarter]

@DeepDiver1975 @MTGap @jancborchardt Any news on this?

In the forum the same was discussed recently: http://forum.owncloud.org/viewtopic.php?f=4&t=16151

To me this actually sounds like a security issue.

Users can, if they're not very careful, possibly share much more than they intended to.

Also, technically, sharing just a subfolder or file inside a folder already shared via public link does not seem to be a problem - share links for subfolder/files created before the share for the parent folder will continue working as expected when creating the parent share link.

"Just" seems to be an issue of how the File view shows those shares. The share by public link in my opinion has to be treated differently than other shares - it may only be shown for exactly the item it was created for.

[PVince81]

Just tried on master, and the following happens: 1) Uncheck "Share with link" for the file in the subdir 2) Close dropdown 3) Open dropdown again 4) Checkbox is still set 5) Uncheck again 6) Error message appars in a popup "Error when unsharing"

If the behavior of not being able to unshare is to be kept, at least the error message must appear the first time (step 2) and should be more user friendly and explain why the action is not possible.

Another alternative is to disable the checkbox with a small message like "Can't unshare within shared dir"

[srfreeman]

I also believe that the noted behavior is 'as intended'. It just seems to follow the standard workings of relational databases and directory/file structures. Public sharing of a file or subfolder, after public sharing of the parent folder, just seems to be a silly idea.

Creating user/group accounts for the various recipients seems to solve the entire issue.

Simple changes to the sharing user's directory structure seems to be another answer.

When 'share by link' is used for simple replacement of an attached file in an email, without regard for file security, there is some limited use. Personally, I feel that the current (general) functionality in the 'share by link' implementation is just another way to transfer data to uncontrolled locations - something that I thought ownCloud was supposed to restrict, not promote.

[jancborchardt]

It doesn’t matter if it follows the standard workings of relational databases. Normal users are not database administrators. ;)

Please remember that sharing by link is not really public. It’s a tokenized unguessable link. A way of sharing wiht people not in your ownCloud. So while you might want to share the whole folder with one person or group, you might only want to share a single file of it with another person.

That’s why this issue report is valid.

[blizzz]

cc @schiesbn

[srfreeman]

@jancborchardt I certainly understand the intent, I just think it is a silly idea.

As I said, there is some limited use to creating a link to a file that bypasses authentication. It just seems to me, when the need is to share an entire directory / tree, account creation is in order. When the account is created and the directory / tree is shared with the internal user, sharing a single file within the tree, by link, is available.

[jancborchardt]

@srfreeman letting people create accounts on your ownCloud is not a solution. We offer folder sharing via link – that’s awesome and should stay that way.

On Sun, Oct 20, 2013 at 10:37 PM, srfreeman notifications@github.comwrote:

@jancborchardt https://github.com/jancborchardt I certainly understand the intent, I just think it is a silly idea.

As I said, there is some limited use to creating a link to a file that bypasses authentication. It just seems to me, when the need is to share an entire directory / tree, account creation is in order. When the account is created and the directory / tree is shared with the internal user, sharing a single file within the tree, by link, is available.

— Reply to this email directly or view it on GitHubhttps://github.com/owncloud/core/issues/3623#issuecomment-26680670 .

[stp-ip]

I still think it's a bug. Sharing publicly (via link) and internally are 2 different things and should work without interfering. sharing internally I want to be able to share directories, files and subdirectories with whom I like and single file sharing nor subdirectory sharing should show the whole parent directory. This is the same with public links. If I want to share a single file I should be able to and it definitely doesn't matter if I already shared the parent directory with some other link.

Sharing /company/ folder via link A to the CTO Sharing /company/marketing folder via link B to Marketing staff -> results in the marketing stuff having the ability to view all files the CTO can see.

That should not be intended. Never. That is circumventing the auth mechanism not using a link.

[srfreeman]

@jancborchardt Of course "letting people create accounts on your ownCloud is not a solution." Accounts should be created by the admin / group admin. I never said otherwise.

[srfreeman]

@stp-ip Internal and external sharing do not interfere with each other. As I noted earlier; "When the account is created and the directory / tree is shared with the internal user, sharing a single file within the tree, by link, is available"

Sharing externally (via link) simply works much the same as allowing several users to share the same account, everyone can see everything. It really makes sense, there is only one 'public' user.

Simple creation of an account for the CTO and accounts / group for the marketing staff makes your scenario workable.

[stp-ip]

@srfreeman I don't see the point in having one public user only. That's just not the usecase. There will always be different access level and it doesn't matter if these access levels use accounts or links. In this case each sharing link should be considered it's own account and therefore each file, directory etc. should be sharable on it's own and not default to the parent directory.

And please account creation is not something you want people to force to. Imagine a payed owncloud and your friends. Or your private owncloud and some work related orga for the next afterwork party.

There are countless points for doing it not this current way.

[srfreeman]

@stp-ip Certainly, each link could be considered its own account, however, if you send the same link to several people, you are still sharing the one account. Creating individual links for everyone is just as much work as creating accounts for everyone, so, what is the point?

Scenario: Paid ownCloud, sharing with friends, no concern for file security. It works fine in the current condition. It can also be called Dropbox.

Scenario: Private ownCloud, organizing a party, no concern for file security. It works fine in the current condition.

Scenario: Private ownCloud, files distributed throughout a company that is concerned with file security and regulatory compliance. Sharing by link does not work in any case and is not enabled by the admin. No need for change here either.

It is simple. If separation of data is required, create accounts. If the data is for relatively public consumption and everyone can see the same thing, go ahead and use the link method.

[stp-ip]

@srfreeman It's just not that simple. Sharing via link is a means of datasharing and reasonably secure for some data and creating user accounts as a solution to a clear design/implementation bug is not a solution. Perhaps there are cases where this design would work DBs, but here it just is not logical for the user that sharing one file could lead to all parent folders being visible via this link. That's not sharing the file by link, that's bad ui/functionality whatever.

Your emphasize on sharing via link has no concern for file security is wrong. Sharing via link has auth and can additionally be inside an internal network. So don't try to explain my "bad" concern for file security, that's not helpful here.

[srfreeman]

@stp-ip I never mentioned 'your' concern for file security (how could I know that?), only that two of the noted scenarios have "no concern for file security" so the noted behavior is not an issue in their case.

Looking for just a bit at the working of relational databases and file systems will point out that the noted behavior is indeed "logical". Whether the functionality is optimal for your use case is a different question entirely.

While the developers of ownCloud may choose to change this functionality, I have only meant to point out that there are many standard ways of accomplishing the same goal without issue.

Using many applications can result in an unintended result when care is not taken in how the application is used. A good application such as Photoshop can produce ugly images, QuickBooks can produce a bad payroll, etc...

Results are a direct function of the usage - it is really very simple.

[jancborchardt]

I can only repeat: I don't care if the current behavior is "logical" in the way relational databases are logical.

This current behavior is an issue and we need to change it. Let's end the discussion and get to fixing it.

[srfreeman]

@jancborchardt What do you propose as a fix?

[jancborchardt]

Well, the fix would be as stated above: Sharing single files within a shared folder should not result in the sharing link being the whole folder, but just that single file.

Anything we can do about this for ownCloud 6? @karlitschek @DeepDiver1975 @butonic @PVince81 or postpone to ownCloud 7?

[schiessle]

fixed for ownCloud6 and oc5.0.14

[RandolfCarter]

Great, thanks very much! :+1:

[neebski]

Fantastic! Thank you! On Nov 15, 2013 2:50 PM, "RandolfCarter" notifications@github.com wrote:

Great, thanks very much! [image: :+1:]

— Reply to this email directly or view it on GitHubhttps://github.com/owncloud/core/issues/3623#issuecomment-28598101 .