[BUG] OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD not correct

[dj4oC]

Finding:
Read-Only Public Shares enforce passwords with oCIS

Expected behavior:

If OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD == false and OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD == true the password should only be enforced for writeable links, not for read only links.

Please fix.

Ref: https://owncloud.dev/services/frontend/#password-enforcement-for-all-public-links

Thank you

ping: @DeepDiver1975 @hosy @felix-schwarz

[DeepDiver1975]

@kobergj are these env vars somehow exposed to the clients via e.g. capabilities or something? THX

[kobergj]

Yes of course. In capabilities: "files_sharing.public.password.enforcedfor"

[felix-schwarz]

@dj4oC This is implemented by the iOS app, with the following logic:

• if files_sharing.public.password.enforced is true, it acts as a "catch-all" and a password is always required, irrespective of whether files_sharing.public.password.enforced_for exists or what it is set to.
• if files_sharing.public.password.enforced is false, a password is only required:

for … links	defined by permissions	if … is true
read-write-delete	read && delete && (create || update)	files_sharing.public.password.enforced_for.read_write_delete
read-write	read && (create || update)	files_sharing.public.password.enforced_for.read_write
upload-only	create	files_sharing.public.password.enforced_for.upload_only
read-only	read	files_sharing.public.password.enforced_for.read_only

This interpretation matches what I could find in the ocis codebase: files_sharing.public.password.enforced appears to be hard-coded to false, while the enforced_for part is configurable individually.

Can you share the full files_sharing.public.password part of the capabilities of an instance you see this issue with?

[dj4oC]

What I know is: if there is a read only share, I can remove the password in Web but I cannot on iOS.

Web is working correctly.

[felix-schwarz]

@dj4oC I'll still need either the full files_sharing.public.password part of the capabilities of an instance you see this issue with - or (even better) a test account to investigate this further and work towards a solution.

[dj4oC]

@dj4oC I'll still need either the full files_sharing.public.password part of the capabilities of an instance you see this issue with - or (even better) a test account to investigate this further and work towards a solution.

If you let me know how to get the information you need, I can provide them

[felix-schwarz]

Ok, after looking into it, I came up with these results:

• upon creating a link, the web UI also forces the user to set a password
• once the link is created, it is possible to remove the password via the context menu
• the server indicates in the capabilities that a password is enforced for read_only:

"password": {
    "enforced_for": {
        "read_only": true,
        "read_write": true,
        "read_write_delete": true,
        "upload_only": true
    },
    "enforced": false
},

To my understanding, if enforced is false, a password is not always enforced, but only for the type of links where enforced_for is true. Is that assumption correct @kobergj?

If it is - and with enforced_for.read_only being true:

• the web client shouldn't offer the context menu option to remove the password
• the server shouldn't allow removing the password
• the OCIS_SHARING_PUBLIC_* options need to be set differently (or interpreted differently) so that read_only is false and the goal is achieved across clients

If it isn't:

• the web client shouldn't enforce setting a password on creation, either (for consistency)
• I need a reference on how else enforced_for and enforced should be interpreted by the app 🙂

(cc @LukasHirt)

[kobergj]

You are absolutely right. You can remove a password even if passwords are enforced. Imho this is a major bug. @dj4oC how can this be expected behaviour? I would suggest to fix this asap.

I need a reference on how else enforced_for and enforced should be interpreted by the app

Here the answer is very simple: enforced will be always false. Therefore there is no need to use it in any way. enforced_for holds the only source of truth

[dj4oC]

No it was intended that you can remove the password for read only shares. So behaviour in web is correct.

Creating a share should enforce the password (security by default) in anyway if there is a password policy for public shares.

Passwords for shares with edit permission cannot be removed.

[kobergj]

@dj4oC So to create a read-only share without passwords I only need to create one with password, then remove it. What's the point in enforcing a password then anyways? Bonus question: Why is this "security by default"?

@felix-schwarz sorry for spamming your ticket 😉

[dj4oC]

@dj4oC So to create a read-only share without passwords I only need to create one with password, then remove it. What's the point in enforcing a password then anyways? Bonus question: Why is this "security by default"?

This is precisely the BSI/LSI obligation we have. It may be possible but the rule says: it is not allowed to CREATE a share without.

[felix-schwarz]

I need a reference on how else enforced_for and enforced should be interpreted by the app

Here the answer is very simple: enforced will be always false. Therefore there is no need to use it in any way. enforced_for holds the only source of truth

Ok, if enforced_for is always false, the iOS app already only looks at enforced_for. ✅

@dj4oC So to create a read-only share without passwords I only need to create one with password, then remove it. What's the point in enforcing a password then anyways? Bonus question: Why is this "security by default"?

This is precisely the BSI/LSI obligation we have. It may be possible but the rule says: it is not allowed to CREATE a share without.

IMO this issue can't be solved as-is. There's a fundamental logical conflict between "passwords are enforced" and "you can just remove it later, so if you don't want to use a password, that's fine, too".

Since that behaviour also isn't documented, I, too, would classify this as a security issue that should be fixed. If admins/orgs choose to enable enforcing passwords, they should be able to rely on them actually being enforced - and that a removal is not possible. Be it by choice or by accident.

Is that BSI/LSI obligation publicly accessible, so it could be referenced in documentation or code comments?

From a technical POV, to support such a behavior transparently and without logical breakage, the password policy part of the capabilities endpoint could be extended, f.ex. via an allow_removal_for, containing the same keys as enforced_for - but this time controlling if pw removal should be allowed for a certain link type.