Server: error shell_exec() has been disabled for security reasons

[MeiRos]

Steps to reproduce

1.Install NC18.0.0 RC1 with PHP 7.4.1
2.Open the NC and go to the settings/system information
3.See log

Expected behaviour

No errors

Actual behaviour

I got errors and for example Can't see network information

Server configuration

Operating system: Centos 7.8

Web server: Nginx 1.17.7

Database: MariaDB 10.3.21
PHP version: 7.4.1

Nextcloud version: Nextcloud 18.0.0 RC1

Updated from an older Nextcloud/ownCloud or fresh install: fresh

Where did you install Nextcloud from: download.nextcloud.com

Signing status:

Signing status

No errors have been found.

List of activated apps:

Only default which are tested

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Logs

Nextcloud log (data/nextcloud.log)

Nextcloud log

Insert your Nextcloud log here
{"reqId":"rgMe4fuvcWCRhoGuelTv","level":3,"time":"2020-01-04T21:14:33+00:00","remoteAddr":"x","user":"admin","app":"PHP","method":"GET","url":"/ocs/v2.php/apps/serverinfo/api/v1//basicdata?format=json","message":"shell_exec() has been disabled for security reasons at /home/nginx/home.net/public/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#96","userAgent":"Mozilla/5.0 (X11; CrOS x86_64 12607.58.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.86 Safari/537.36","version":"18.0.0.8","id":"5e1101566eed7"}

{"reqId":"rgMe4fuvcWCRhoGuelTv","level":3,"time":"2020-01-04T21:14:33+00:00","remoteAddr":"x","user":"admin","app":"PHP","method":"GET","url":"/ocs/v2.php/apps/serverinfo/api/v1//basicdata?format=json","message":"shell_exec() has been disabled for security reasons at /home/nginx/home.net/public/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#95","userAgent":"Mozilla/5.0 (X11; CrOS x86_64 12607.58.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.86 Safari/537.36","version":"18.0.0.8","id":"5e1101566eee8"}

{"reqId":"rgMe4fuvcWCRhoGuelTv","level":3,"time":"2020-01-04T21:14:33+00:00","remoteAddr":"x","user":"admin","app":"PHP","method":"GET","url":"/ocs/v2.php/apps/serverinfo/api/v1//basicdata?format=json","message":"shell_exec() has been disabled for security reasons at /home/nginx/home.net/public/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#87","userAgent":"Mozilla/5.0 (X11; CrOS x86_64 12607.58.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.86 Safari/537.36","version":"18.0.0.8","id":"5e1101566eef5"}

{"reqId":"rgMe4fuvcWCRhoGuelTv","level":3,"time":"2020-01-04T21:14:33+00:00","remoteAddr":"x","user":"admin","app":"PHP","method":"GET","url":"/ocs/v2.php/apps/serverinfo/api/v1//basicdata?format=json","message":"shell_exec() has been disabled for security reasons at /home/nginx/home.net/public/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#79","userAgent":"Mozilla/5.0 (X11; CrOS x86_64 12607.58.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.86 Safari/537.36","version":"18.0.0.8","id":"5e1101566ef01"}

According to this https://github.com/nextcloud/serverinfo/issues/50 the issue is known.
It's fixed and it's still in use here. Is it safe nowadays to enable shell_exec?

[kesselb]

According to this nextcloud/serverinfo#50 the issue is known.

And why do you create a issue at nextcloud/server then? :confused:

Is it safe nowadays to enable shell_exec

No. I'm really confused by this question. shell_exec will execute a shell command. So that's still unsafe (how should that change?). Serverinfo will show information about the system like cpu usage, memory usage. Those information are fetched via shell_exec (e.g. https://github.com/nextcloud/serverinfo/blob/a7e2609e668172ab04815e72c619692c2c4c41a6/lib/OperatingSystems/DefaultOs.php#L50).

If you want to use Nextcloud without shell_exec disable the monitoring app. Also the previews for office files will not work. There is more code using shell_exec: https://github.com/search?l=PHP&q=shell_exec+org%3Anextcloud+repo%3Anextcloud%2Fserver&type=Code It will probably work for you without shell_exec.

[kesselb]

Thanks for reporting this. Closing this issue:

1) Wrong repository
2) Expected behaviour is impossible. Without shell_exec no information.

[MeiRos]

According to this nextcloud/serverinfo#50 the issue is known.

And why do you create a issue at nextcloud/server then?

Because the problem is still here. In the Nextcloud server number 18. Maybe was fixed in Nextcloud 11 (at least partially). Why are you still using the same unsafe method?

Is it safe nowadays to enable shell_exec

No. I'm really confused by this question. shell_exec will execute a shell command. So that's still unsafe (how should that change?). Serverinfo will show information about the system like cpu usage, memory usage. Those information are fetched via shell_exec (e.g. https://github.com/nextcloud/serverinfo/blob/a7e2609e668172ab04815e72c619692c2c4c41a6/lib/OperatingSystems/DefaultOs.php#L50).

And I'm really confused because you still use unsafe methods. I really thought that's fixed in someway.

If you want to use Nextcloud without shell_exec disable the monitoring app. Also the previews for office files will not work. There is more code using shell_exec: https://github.com/search?l=PHP&q=shell_exec+org%3Anextcloud+repo%3Anextcloud%2Fserver&type=Code It will probably work for you without shell_exec.

Of course I want to have more safe Nextcloud. Thank you for the information.

[MeiRos]

Thanks for reporting this. Closing this issue:

1. Wrong repository
2. Expected behaviour is impossible. Without shell_exec no information.

1. Sorry
2. Thank you

[kesselb]

Would you mind to log a issue at nextcloud/serverinfo? I missed the fact that for Linux we should be able to fetch most of these information from /proc. Abstraction is already in place. So adding another backend LinuxOs (that extends DefaultOs) should be possible. Thanks in advance :+1:

[n-l]

How about putting a warning at the top of the Monitoring page about some info being unavailable instead of filling up the log with this message?

[puntorosso]

There's a solution for this error message in log? As n-l commented, it would be enough to show a warning, instead of writing every 10 seconds an error in log.