Colon in folder name followed by a number creates fatal error

[tflidd]

Steps to reproduce

1. Create user1 and user2
2. user1 shares folder share with user2
3. user1 syncs share with desktop client
4. user2 creates folder today 12:00

Expected behaviour

folder today 12:00 is synced or if colons are impossible in the OS it should be ignored.

Actual behaviour

Internal server error

Logs

Web server error log

2016/07/14 12:14:47 [error] 14916#0: *1128 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Unsupported operand types in /var/www/owncloud/3rdparty/sabre/uri/lib/functions.php on line 181" while reading response header from upstream, client: 192.168.2.131, server: _, request: "PROPFIND /remote.php/webdav/share/today%2012:00 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.2.6"

reported by user on the forum: https://forum.owncloud.org/viewtopic.php?f=38&t=37741 (OC 9.0.3, client 2.2.2 on OS X), more details not known (yet)

I verified this on a rPI2:

Server configuration

Operating system: Raspbian 8

Web server: Nginx

Database: Mysql

PHP version: php 5.6

ownCloud version: 9.0.3

Updated from an older ownCloud or fresh install: 9.0.0

Where did you install ownCloud from: repo

Signing status (ownCloud 9.0 and above): good

It's a basic setup, no 3rd-party apps, no encryption, no proxy, no external storage.

Client 2.2.2 shows error (Ubuntu 16.04/OS X).

[PVince81]

Hmmmm, indeed. I thought it was php-fpm specific but it also happens in my mod_php instance.

[PVince81]

It used to work in 8.1 => regression. I suspect it could be due to a Sabre lib update where URL handling might be different.

Will try and find where it broke.

[PVince81]

stable8.2 is fine, stable9 is broken

[PVince81]

Indeed, it's the update to Sabre 3 eacb24c

CC @DeepDiver1975

Let's see what needs adjusting

[PVince81]

Hmmmm... I tried writing a test but the test will properly URL encode the colon.
However the desktop client doesn't.

[PVince81]

Reproducible with a non-encoded colon:

% curl -D - -X MKCOL http://admin:admin@localhost/owncloud/remote.php/webdav/colon%2010:14

It seems Sabre URI uses parse_url from PHP and that one doesn't seem to like colons.

Ohhhh, it's even weirder: it's only with colon followed by numbers !

This works:

% curl -D - -X MKCOL http://admin:admin@localhost/owncloud/remote.php/webdav/colon%2010:abc

Found this: https://bugs.php.net/bug.php?id=55511

[PVince81]

This is with php5-5.6.23-1.1.x86_64

@DeepDiver1975 do you see this behavior with PHP7 ?

[PVince81]

Two solutions:

1. Patch + send PR upstream in Sabre URI https://github.com/fruux/sabre-uri/blob/master/lib/functions.php#L188 to also encode ":" when not encoded (CC @evert)

and/or

1. Ask the clients to encode colons in URLs

[DeepDiver1975]

@DeepDiver1975 do you see this behavior with PHP7 ?

let me try this ...

[DeepDiver1975]

same with php7

[PVince81]

Can a regexp expert tell me how to adjust https://github.com/fruux/sabre-uri/blob/master/lib/functions.php#L188 to also include the colon ? All my attempts failed...

These never seem to match the colon:
'/[^[:ascii:]:]/u',, '/[^[:ascii:]\:]/u', '/[^[:ascii:]\\:]/u',

[guruz]

don't include the colon, it's where to body stores 💩

[RobinMcCorkell]

@PVince81 The regexes you've posted are negated by the ^, try '/(?:[^[:ascii:]]|:)/u' instead (the?:` makes the group non-capturing, and it either matches a non-ASCII character or a colon)

[evert]

This would also escape the colon in the schema.

I think that PHP bug should be reopened though with better clarification and lining up with what rfc3986 says about this.

If we can get the PHP guys to confirm that it is indeed a bug, I think that that would be a better basis for creating the workaround for sabre/uri.

Make sure that whatever change you're making doesn't create incorrect result when the intention of the uri is to actually include a tcp port.

[PVince81]

Any volunteer to report this upstream on the PHP bugtracker ? Possibly someone who already has an account there.

[PVince81]

Workaround would be to have the clients url encode the colon.

But it seems indeed to be a PHP bug, see https://bugs.php.net/bug.php?id=55511

[PVince81]

Apparently the web UI properly encodes the colon, probably because we use encodeURIComponent which does that. That's why it does work in the web UI.

[PVince81]

Instead of patching Sabre\URI maybe patching Sabre\Request::getPath instead to pre-encode the colon so that when we pass it to Sabre\URI::parse it will work...

[PVince81]

WIP PR here that adds a test to reproduce the issue: #26773

The final fix will require upgrading sabre/uri after sabre-io/uri#9 is released

[JKawohl]

This is also related: https://github.com/owncloud/enterprise/issues/1692

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.