owncloud / core

:cloud: ownCloud web server core (Files, DAV, etc.)
https://owncloud.com
GNU Affero General Public License v3.0
8.34k stars 2.06k forks source link

Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed #38263

Closed created4el closed 3 years ago

created4el commented 3 years ago
### Steps to reproduce 1. server is debian 10.4 2. owncloud version 10.6.0.5 but this issue has been a problem for at least the two previous versions 3. After installing, attempted to access the installation using firefox 68.10.0 ### Expected behaviour this was a working system but after an upgrade and several attempts to upgrade since, has been broken. Now, all I get is the message: Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed ### Actual behaviour Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed and it doesn't allow any login or anything else. ### Server configuration **Operating system**: Debian 10.4 **Web server:** Apache 2.4.38 **Database:** mysql **PHP version:** 7.3 **ownCloud version:** (see ownCloud admin page) 10.6.0.5 **Updated from an older ownCloud or fresh install:** untarred owncloud-complete-20201216.tar.bz2 into a new directory then moved the data directory from the older install to the new one and then made changes to the config.php file **Where did you install ownCloud from:** ? (don't know what this means... I tried different things to install... one using the debian synaptic package manager after inserting the appropriate link into /etc/apt/sources.list file but finally resorted to downloading the latest from owncloud.com and untarred as mentioned above **Signing status (ownCloud 9.0 and above):** (no idea what this means) ``` Login as admin user into your ownCloud and access http://example.com/index.php/settings/integrity/failed paste the results into https://gist.github.com/ and puth the link here. can't log in as anything... ``` I noticed that there are two files that are involved in this issue: ./lib/private/legacy/util.php ./lib/composer/patchwork/utf8/src/Patchwork/Utf8/Bootup.php in util.php, the isSetLocaleWorking() function uses "basenamee('§')" to determine what to do. And based on the lack of change in behavior from "basename()" the check decides that setlocale didn't happen. This indirect method seems to be problematic. I have added a print statement into Bootup.php and then ran sudo -u www-data php occ config:list system before setlocale LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
before setlocale LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
{ "system": { "instanceid": "ocd1ys2lr679", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "cloud.samcamp.org" ], "cors.allowed-domains": [ "https:\/\/cloud.samcamp.org" ], "datadirectory": "\/var\/www_owncloud\/data", "crashdirectory": "\/var\/www_owncloud\/data", "version": "10.6.0.5", "version.hide": false, "show_server_hostname": false, "use_relative_domain_name": false, "dbtype": "mysql", "dbhost": "localhost", "dbname": "samcampcloud", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "installed": true, "default_language": "en_US", "defaultapp": "files", "enable_avatars": true, "allow_user_to_change_display_name": true, "remember_login_cookie_lifetime": 1296000, "session_lifetime": 1200, "session_keepalive": true, "token_auth_enforced": false, "strict_login_enforced": false, "login.alternatives": [], "csrf.disabled": false, "skeletondirectory": "\/var\/www_owncloud\/owncloud\/core\/skeleton", "user_backends": [ { "class": "OC_User_IMAP", "arguments": [ "{imap.gmail.com:993\/imap\/ssl}INBOX" ] } ], "lost_password_link": "", "accounts.enable_medial_search": true, "groups.enable_medial_search": true, "user.search_min_length": 2, "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_smtpdebug": false, "mail_smtpmode": "sendmail", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": 25, "mail_smtptimeout": 10, "mail_smtpsecure": "", "mail_smtpauth": false, "mail_smtpauthtype": "LOGIN", "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "overwritehost": "", "overwriteprotocol": "", "overwritewebroot": "", "overwritecondaddr": "", "overwrite.cli.url": "", "web.baseUrl": "", "htaccess.RewriteBase": "\/", "proxy": "", "proxyuserpwd": "***REMOVED SENSITIVE VALUE***", "trashbin_retention_obligation": "auto", "trashbin_purge_limit": 50, "versions_retention_obligation": "auto", "updatechecker": true, "updater.server.url": "https:\/\/updates.owncloud.com\/server\/", "has_internet_connection": true, "check_for_working_wellknown_setup": true, "config_is_read_only": false, "operation.mode": "single-instance", "log_type": "owncloud", "logfile": "\/var\/log\/owncloud.log", "loglevel": 2, "syslog_tag": "ownCloud", "log.syslog.format": "[%reqId%][%remoteAddr%][%user%][%app%][%method%][%url%] %message%", "log.conditions": [ { "shared_secret": "***REMOVED SENSITIVE VALUE***", "users": [ "user1" ], "apps": [ "files_texteditor" ], "logfile": "\/tmp\/test.log" }, { "shared_secret": "***REMOVED SENSITIVE VALUE***", "users": [ "user1" ], "apps": [ "files_mediaviewer" ], "logfile": "\/tmp\/mediaviewer.log" } ], "logdateformat": "F d, Y H:i:s", "logtimezone": "Europe\/Berlin", "cron_log": true, "log_rotate_size": false, "apps_paths": [ { "path": "\/var\/www_owncloud\/owncloud\/apps", "url": "\/apps", "writable": false }, { "path": "\/var\/www_owncloud\/owncloud\/apps-external", "url": "\/apps-external", "writable": true } ], "enable_previews": true, "previews_path": "", "preview_max_x": 2048, "preview_max_y": 2048, "preview_max_scale_factor": 10, "preview_max_filesize_image": 50, "preview_libreoffice_path": "\/usr\/bin\/libreoffice", "0": "--convert-to pdf --outdir ", "enabledPreviewProviders": [ "OC\\Preview\\PNG", "OC\\Preview\\JPEG", "OC\\Preview\\GIF", "OC\\Preview\\BMP", "OC\\Preview\\XBitmap", "OC\\Preview\\MP3", "OC\\Preview\\TXT", "OC\\Preview\\MarkDown" ], "comments.managerFactory": "\\OC\\Comments\\ManagerFactory", "systemtags.managerFactory": "\\OC\\SystemTag\\ManagerFactory", "maintenance": false, "singleuser": false, "openssl": { "config": "\/etc\/ssl\/openssl.cnf" }, "enable_certificate_management": false, "memcache.local": "\\OC\\Memcache\\APCu", "memcached_servers": [ [ "localhost", 11211 ] ], "memcached_options": { "14": 50, "15": 50, "19": 50, "20": 50, "8": 50, "-1001": true, "16": true, "18": true }, "cache_path": "", "cache_chunk_gc_ttl": 86400, "dav.chunk_base_dir": "", "sharing.managerFactory": "\\OC\\Share20\\ProviderFactory", "sharing.federation.allowHttpFallback": false, "sqlite.journal_mode": "DELETE", "mysql.utf8mb4": false, "supportedDatabases": [ "sqlite", "mysql", "pgsql", "oci" ], "tempdirectory": "\/tmp\/owncloudtemp", "hashingCost": 10, "blacklisted_files": [ ".htaccess" ], "blacklisted_files_regex": [ ".*\\.ext", "^somefilename.*" ], "excluded_directories": [ ".snapshot", "~snapshot" ], "excluded_directories_regex": [ "^backup.*", ".*backup$" ], "integrity.excluded.files": [ ".DS_Store", "Thumbs.db", ".directory", ".webapp", ".htaccess", ".user.ini" ], "integrity.ignore.missing.app.signature": [ "app-id of app-1", "app-id of theme-2" ], "share_folder": "\/", "cipher": "AES-256-CFB", "minimum.supported.desktop.version": "2.3.3", "quota_include_external_storage": false, "filesystem_check_changes": 0, "filesystem.max_mountpoint_move_attempts": 10, "part_file_in_storage": true, "mount_file": "\/var\/www\/owncloud\/data\/mount.json", "filesystem_cache_readonly": false, "secret": "***REMOVED SENSITIVE VALUE***", "trusted_proxies": [ "203.0.113.45", "198.51.100.128" ], "forwarded_for_headers": [ "HTTP_X_FORWARDED", "HTTP_FORWARDED_FOR" ], "max_filesize_animated_gifs_public_sharing": 10, "filelocking.enabled": true, "filelocking.ttl": 3600, "memcache.locking": "\\OC\\Memcache\\Redis", "upgrade.disable-web": false, "upgrade.automatic-app-update": true, "debug": false, "data-fingerprint": "", "files_external_allow_create_new_local": false, "smb.logging.enable": false, "dav.enable.async": false, "grace_period.demo_key.show_popup": true, "grace_period.demo_key.link": "https:\/\/owncloud.com\/try-enterprise\/", "theme": "" } } So, you'll notice that print "before setlocale " . setlocale(LC_ALL, 0) . "
\n"; printed twice but there was no "after setlocale" indicating that the code didn't go through the check for basename to set the locale. In other words, the check for "basename()" seemed to have favorable results. But when leaving those print statements in Bootup.php but making an http call the print statements return before setlocale C setting locale after setlocale LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C.UTF-8;LC_TIME=C.UTF-8;LC_COLLATE=C.UTF-8;LC_MONETARY=C.UTF-8;LC_MESSAGES=C.UTF-8;LC_PAPER=C.UTF-8;LC_NAME=C.UTF-8;LC_ADDRESS=C.UTF-8;LC_TELEPHONE=C.UTF-8;LC_MEASUREMENT=C.UTF-8;LC_IDENTIFICATION=C.UTF-8 notice a couple of things: 1) the code went into Bootup.php and ran my print statements, and specifically the before and after setlocale was called which changes the value returned by setlocale(LC_All,0) 2) setlocale clearly worked in the webserver but running occ from the commandline, setlocale value is different between commandline and web server. And so if I just change the return value in util.php for this check to return "true" instead of "false" as it is coded to do, then everything seems to work just fine. I now get the login prompt instead of the error message. Obviously when running things from the command line will differ from a webserver running things but if there is a setting that I am not setting for the web server then I don't know what it is. I've combed through a lot of web searches which say to set various things and to restart the web server which I have done. But clearly there is a bug if setlocale is changing the the value after the setlocale operation in Bootup.php which wasn't detected by the method put in place indicating it isn't a problem with my system variables but a fundamental flaw in using "basename()" to see if its behavior changes before and after the setlocale statement is executed. ``` Log in to the web-UI with an administrator account and click on 'admin' -> 'Generate Config Report' -> 'Download ownCloud config report' This report includes the config.php settings, the list of activated apps and other details in a well sanitized form. or If you have access to your command line run e.g.: sudo -u www-data php occ config:list system from within your ownCloud installation folder *ATTENTION:* Do not post your config.php file in public as is. Please use one of the above methods whenever possible. Both, the generated reports from the web-ui and from occ config:list consistently remove sensitive data. You still may want to review the report before sending. If done manually then it is critical for your own privacy to dilligently remove *all* host names, passwords, usernames, salts and other credentials before posting. You should assume that attackers find such information and will use them against your systems. ``` **List of activated apps:** ``` If you have access to your command line run e.g.: sudo -u www-data php occ app:list from within your ownCloud installation folder. ``` **Are you using external storage, if yes which one:** local/smb/sftp/... **Are you using encryption:** yes/no **Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/... #### LDAP configuration (delete this part if not used) ``` With access to your command line run e.g.: sudo -u www-data php occ ldap:show-config from within your ownCloud installation folder Without access to your command line download the data/owncloud.db to your local computer or access your SQL server remotely and run the select query: SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap'; Eventually replace sensitive data as the name/IP-address of your LDAP server or groups. ``` ### Client configuration **Browser:** **Operating system:** ### Logs #### Web server error log ``` Insert your webserver log here ``` #### ownCloud log (data/owncloud.log) ``` Insert your ownCloud log here ``` #### Browser log ``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ```
created4el commented 3 years ago

THE PROBLEM WAS NOT IN APACHE!

I have uncommented the './etc/default/locale' line in /etc/apache2/envars and this did not solve the problem. That is one of the things I have tried. And after trying many things, this is why I reported this issue. (note: I also restarted apache after uncommenting that line so don't presume I didn't)

Even if that did cause the problem to go away, that doesn't come to suggest that your code works as intended as outlined in the original report that I posted.

Just to reiterate, I added print statements into the Bootup.php file to positively identify that the locale was set in the code but when it returned, it still determined that the locale was not set despite it being set. That is a bug.

Specifically:

./lib/private/legacy/util.php: isSetLocaleWorking() relies on the behavioral change of basename() after calling ./lib/composer/patchwork/utf8/src/Patchwork/Utf8/Bootup.php : initLocale(). But after initLocale() executes the setlocale() function and returns, isSetLocaleWorking() does not detect that the setlocale() was executed because the behavior of the basename() has not changed. This is a fundamental bug in the code!

It seems to me that it would be easier, and more direct and therefore more reliable to do a setlocale(LC_ALL, 0) or setlocale(LC_CTYPE,0) and search the return value for UTF-8 or some variation if all systems do not return something specifically with UTF-8 in it, i.e. if they return something with utf8 or utf-8 instead of UTF-8. Using this as a check would definitely work in my system and if you are trying to setlocale, it seems to me the positive check to see if "isSetLocaleWorking" is to see if the value changed from before executing the setlocale() function and after.

There is one caveat... according to www.php.net documentation on setlocale(), it indicates that when using multithreading, the threads might not be in sync when using setlocale(). I haven't looked close enough at your code to know if you are using multithreading but if you are then this may be the root of your issue regarding the setting of the setlocale() behavior and what motivated you to use such a strange and unreliable approach for detecting if setlocale is working.

created4el commented 3 years ago

@ho4ho... are you asking me to uninstall php-intl, which is installed by default when installing php, and then try again?

You stated this is not your code. The code has a flaw that has nothing to do, as far as I'm concerned, with php-intl. I got my code working by doing just what I stated. So, I'm not sure what you are asking and why if this is not your code. I don't have time to try things just for academic purposes.

AlexAndBear commented 3 years ago

should be resolved with https://github.com/owncloud/core/pull/38315

DagNygren commented 1 year ago

Well. This was fixed and worked fine for some time but now it is back again. Have had to make isSetLocaleWorking always return true by hand in the last few minor releases. Now at 24.0.7 which has this problem. I do not remember when it turned up again, but my guess is somewhere around 24.0.0

DagNygren commented 1 year ago

And you are right, of course. This is Nextcloud. Sorry.

mvl22 commented 1 year ago

Running Owncloud version 10.11.0 on Ubuntu 20.04, I am still finding that it is necessary to uncomment the ./etc/default/locale line in /etc/apache2/envvars.

Oddly I do have the local installed on the system:

# locale -a | grep en_US
en_US
en_US.iso88591
en_US.utf8

Is there any progress in removing this requirement? Having to alter a standard core Apache file just to run a PHP application is obviously really not good.