Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: flood of errors is_file(): open_basedir restriction in effect. File(/proc/cpuinfo) after 25 > 26 update #37921

Closed
6 of 9 tasks
willemb2 opened this issue Apr 25, 2023 · 18 comments · Fixed by #37959
Closed
6 of 9 tasks

Comments

@willemb2
Copy link

willemb2 commented Apr 25, 2023

⚠️ This issue respects the following points: ⚠️

  • This is a bug, not a question or a configuration/webserver/proxy issue.
  • This issue is not already reported on Github (I've searched it).
  • Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
  • Nextcloud Server is running on 64bit capable CPU, PHP and OS.
  • I agree to follow Nextcloud's Code of Conduct.

Bug description

After updating Nextcloud server from 25.0.6 to 26.0 every activity results in an error in the log like:

[PHP] Error: is_file(): open_basedir restriction in effect. File(/proc/cpuinfo) is not within the allowed path(s): (/home/<account>/:/tmp:/var/tmp:/opt/alt/php74/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php74/lib/php/) at /home/<account>/domains/example.com/public_html/cloud/lib/private/Preview/Generator.php#351

GET /index.php/core/preview?fileId=464&c=c5edf881068c4f84bc6c9eb94f3cdcc9&x=375&y=375&forceIcon=0&a=1
from 2a10:3781:15:1:64d0:faf:896:88ea by <admin account> at 2023-04-23T20:44:04+00:00

This never occurred before the update (installed may 2022)

Steps to reproduce

  1. Install Nextcloud on shared hosting using the web installer
  2. Use it for a year without notable issues
  3. Update from 25.0.6 to 26.0
  4. Look in Administration settings > Logging

Expected behavior

Clean log or only warnings

Installation method

Community Web installer on a VPS or web space

Nextcloud Server version

26

Operating system

RHEL/CentOS

PHP engine version

PHP 8.1

Web server

Other

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 22.2.3 to 23.0.1)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

No SSH acces, but this is what the Support link provides:

Server configuration detail

Operating system: Linux 3.10.0-962.3.2.lve1.5.79.el7.x86_64 #1 SMP Wed Mar 15 09:10:44 UTC 2023 x86_64

Webserver: Apache/2 (litespeed)

Database: mysql 10.3.38

PHP version: 8.1.17

Modules loaded: Core, date, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, json, iconv, SPL, pcntl, readline, Reflection, session, standard, mbstring, shmop, SimpleXML, tokenizer, xml, litespeed, bcmath, dom, fileinfo, gd, imagick, imap, intl, exif, mcrypt, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, soap, sockets, sodium, sysvsem, xmlreader, xmlwriter, xsl, zip, ionCube Loader, Zend OPcache

Nextcloud version: 26.0.1 - 26.0.1.1

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "cloud.example.com"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "26.0.1.1",
    "overwrite.cli.url": "https:\/\/cloud.example.com",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "mail_smtpmode": "smtp",
    "mail_smtpsecure": "tls",
    "mail_sendmailmode": "smtp",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "587",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpauthtype": "LOGIN",
    "mail_smtpauth": 1,
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "maintenance": false,
    "theme": "",
    "loglevel": 2,
    "default_language": "nl",
    "default_locale": "nl_NL",
    "defaultapp": "files",
    "default_phone_region": "NL",
    "skeletondirectory": "\/home\/<account>\/domains\/example.com\/public_html\/clouddata\/skeleton",
    "templatedirectory": ""
}

List of activated Apps

Enabled:
 - activity: 2.18.0
 - auto_groups: 1.5.1
 - bruteforcesettings: 2.6.0
 - circles: 26.0.0
 - cloud_federation_api: 1.9.0
 - comments: 1.16.0
 - contactsinteraction: 1.7.0
 - dashboard: 7.6.0
 - dav: 1.25.0
 - federatedfilesharing: 1.16.0
 - federation: 1.16.0
 - files: 1.21.1
 - files_external: 1.18.0
 - files_pdfviewer: 2.7.0
 - files_rightclick: 1.5.0
 - files_sharing: 1.18.0
 - files_trashbin: 1.16.0
 - files_versions: 1.19.1
 - firstrunwizard: 2.15.0
 - logreader: 2.11.0
 - lookup_server_connector: 1.14.0
 - nextcloud_announcements: 1.15.0
 - notifications: 2.14.0
 - oauth2: 1.14.0
 - password_policy: 1.16.0
 - photos: 2.2.0
 - privacy: 1.10.0
 - provisioning_api: 1.16.0
 - recommendations: 1.5.0
 - related_resources: 1.1.0-alpha1
 - settings: 1.8.0
 - sharebymail: 1.16.0
 - support: 1.9.0
 - survey_client: 1.14.0
 - systemtags: 1.16.0
 - text: 3.7.2
 - theming: 2.1.1
 - twofactor_backupcodes: 1.15.0
 - updatenotification: 1.16.0
 - user_status: 1.6.0
 - viewer: 1.10.0
 - workflowengine: 2.8.0
Disabled:
 - admin_audit
 - apporder: 0.15.0
 - backup: 1.2.0
 - encryption
 - groupfolders: 14.0.1
 - serverinfo: 1.14.0
 - suspicious_login
 - twofactor_totp
 - user_ldap
 - weather_status: 1.4.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Hundreds of:

[PHP] Error: is_file(): open_basedir restriction in effect. File(/proc/cpuinfo) is not within the allowed path(s): (/home/<account>/:/tmp:/var/tmp:/opt/alt/php74/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php74/lib/php/) at /home/<account>/domains/example.com/public_html/cloud/lib/private/Preview/Generator.php#351

GET /index.php/core/preview?fileId=464&c=c5edf881068c4f84bc6c9eb94f3cdcc9&x=375&y=375&forceIcon=0&a=1
from 2a10:3781:15:1:64d0:faf:896:88ea by <admin account> at 2023-04-23T20:44:04+00:00

Additional info

See this forum topic.

This has similarities with #27759 but that one is closed, was generated by a different .php and was about different directories so IMHO this a new bug.

Like on most shared hosting we cannot edit php.ini but the DirectAdmin panel allowed us to add /proc/cpuinfo to the open_basedir. I still believe this should not be needed.

Opinions I heard/read, but I'm no developer, so I cannot judge:

  • Our provider: "open_basedir? Are they really using that?

In the forum topic mentioned above:

On php.net:

Caution

open_basedir is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed.
@willemb2 willemb2 added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Apr 25, 2023
@solracsf

This comment was marked as resolved.

@solracsf solracsf added 2. developing Work in progress and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Apr 25, 2023
@willemb2

This comment was marked as resolved.

@solracsf
Copy link
Member

solracsf commented Apr 25, 2023

Thanks. Mind to try:

public static function getHardwareConcurrency(): int {
	static $width;
	if (!isset($width)) {
		if (function_exists('ini_get')) {
			$openBasedir = ini_get('open_basedir');
			if ($openBasedir == '') {
				$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
			} else {
				$openBasedirPaths = explode(':', $openBasedir);
				foreach ($openBasedirPaths as $path) {
					if (strpos($path, '/proc') === 0 || $path === '/proc/cpuinfo') {
						$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
					} else {
						$width = 0;
					}
				}
			}
		} else {
			$width = 0;
		}
	}
	return $width;
}

@kesselb
Copy link
Contributor

kesselb commented Apr 25, 2023

In serverinfo we are using @file_get_contents('/proc/cpuinfo').
The @ operator will supress the open basedir warning:

php -d open_basedir=/var/www -r "var_dump(file_get_contents('/proc/cpuinfo'));"
php -d open_basedir=/var/www -r "var_dump(@file_get_contents('/proc/cpuinfo'));"

To read /proc/cpuinfo every time we need a preview generator is a bit weird.
I would prefer a static value with a sensible default instead of this magic. Too much magic is just calling for trouble.

@solracsf
Copy link
Member

Sure, but I just hate @ 😆
But if that's the way to go...

@kesselb
Copy link
Contributor

kesselb commented Apr 25, 2023

I understand. It was just a suggestion. If you prefer to check open_basedir go ahead.

The runtime check for the number of cores is weird anyway. It's unlikely to change ;)

@solracsf
Copy link
Member

The runtime check for the number of cores is weird anyway. It's unlikely to change ;)

Agree.

@willemb2
Copy link
Author

willemb2 commented Apr 25, 2023

Thanks. Mind to try:

public static function getHardwareConcurrency(): int {
  static $width;
  if (!isset($width)) {
  	if (function_exists('ini_get')) {
  		$openBasedir = ini_get('open_basedir');
  		if ($openBasedir == '') {
  			$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
  		} else {
  			$openBasedirPaths = explode(':', $openBasedir);
  			foreach ($openBasedirPaths as $path) {
  				if (strpos($path, '/proc') === 0 || $path === '/proc/cpuinfo') {
  					$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
  				} else {
  					$width = 0;
  				}
  			}
  		}
  	} else {
  		$width = 0;
  	}
  }
  return $width;
}

That seems to work. I'm not getting new errors. I cannot say something usefull about performance. This is a very small setup, around 10 users, < 100 documents.

@joshtrichards
Copy link
Member

Regarding this:

Opinions I heard/read, but I'm no developer, so I cannot judge:

  • Our provider: "open_basedir? Are they really using that?

NC isn't using open_basedir - your provider is (in their PHP stack config) and it's preventing a newer NC feature from working (albeit one that has some alternatives on the NC side).

@willemb2
Copy link
Author

OK, I'll tell them. From the forum topic linked above I understand that you can disable it if you have access to php.ini, but we don't. In Directadmin I don't see an option to disable it. Probably only an admin can. The same with cPanel at another provider where I'm hosting a website.

@joshtrichards
Copy link
Member

joshtrichards commented Apr 25, 2023

OK, I'll tell them. From the forum topic linked above I understand that you can disable it if you have access to php.ini, but we don't. In Directadmin I don't see an option to disable it. Probably only an admin can. The same with cPanel at another provider where I'm hosting a website.

Yes, open_basedir is controlled by administrators in shared hosting environments. And if you're using shared hosting, you're going to have a far lower level of access to the server and the control panel capabilities. You're stuck with whatever you can do within the confines of the access the provider chooses to give you the ability to do and whatever they consider a "standard" configuration internally.

Control panels (e.g. Directadmin/cPanel) aren't the issue per se - you can install them on your own VPS (versus shared web hosting) if you like - and enjoy full access to do as you please. :-)

@willemb2
Copy link
Author

willemb2 commented Apr 27, 2023

So the elegant solution by @solracsf did not make it through review. It worked for us although I got the feeling that viewing folders got a little slower.

(...)
The runtime check for the number of cores is weird anyway. It's unlikely to change ;)

Isn't that the underlying problem that needs to be fixed?

Some more thoughts: I'm running Nextcloud on my own server at home but also on shared hosting for 2 associations. This kind of usage is in the official documentation and the 'web installer' I used is promoted on nextcloud.com. Also, many hosting providers offer Installatron, which probably also runs the web installer. I assume this installer checks for some requirements for Nextcloud. In fact we do get some warnings about missing PHP extensions required for certain functionality. But nothing about open_basedir.

IMHO it is important to make and keep Nextcloud working on shared hosting with some basic functionality. It helps 'spread the word'. It has worked fine for us so far and it made at least one member get a commercial Nextcloud solution for his company.

@solracsf
Copy link
Member

solracsf commented Apr 27, 2023

It worked for us although I got the feeling that viewing folders got a little slower.

Read the code and explain how could it be slower :) It just checks if the function can be called, nothing more.

Beside that, the function is already static:

static $width;

I've submitted the PR here.

@willemb2
Copy link
Author

Sorry, I was referring to your getconf() solution PR #37923. Had not seen #37959 yet. I can't read PHP code but I just tested the new one and it works fine, no error and it feels responsive. Thanks for handling this so quickly!

@Siggi0904
Copy link

Hi, still occurs in Nexcloud 26.0.2.
Please fix it in Nexloud 26.0.3 quite soon.
That would be really nice.

@camouflage81
Copy link

Have the issue still in version 27.0.1.

@flotzMAN
Copy link

Me too. Have this Issue since v26.0.0. Yesterday i updated to v27.0.1. Is still there.

@Siggi0904
Copy link

looks like it will be only fixed in nc 28.
Please backport that fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants