os:cmd() invokes access() syscall as part of detecting which shell to use

[yarisx]

Describe the bug
Since OTP25 the os:cmd() function via its helper os:mk_cmd() tries to determine which shell to use (to accommodate to Android's non-standard shell placement) by calling file:read_file_info(), which in turn invokes access() syscall with R_OK and W_OK flags. This causes issues in some secured environments where only read access to the shell is allowed. Moreover reading the whole inode of data only to check that the file exists looks unnecessary.

To Reproduce
In Linux: from Erlang shell call os:cmd("ls") while using strace -f -e trace=access on the Erlang VM process.

Expected behavior
os:cmd() should check the location of the system shell without reading a lot of info from the filesystem and triggering security modules like SELinux and AppArmor.

Affected versions
OTP25 and further

Additional context
It seems to be possible to use the access() syscall with F_OK flag to just check whether the file exists or not.
Probably it would be beneficial to have a separate file:check_access/2 function to check access rights on the file without reading all other data about it or opening (and immediately closing) it.

[garazdawi]

Another approach would be to add a configuration parameter to kernel, that lets the user decide which shell to use. Doing a config lookup should not be very expensive in the big scheme of things.

What do you think?

[yarisx]

Yes, the config option would work to select the shell.
But our wish for file:check_access/2 still stays :-) We often check read/write access to files (logs, credentials etc) but we are not interested in other metadata for those files. Probably it should be a matter of another PR though.

[garazdawi]

Yes, the config option would work to select the shell.

Will you send a PR?

But our wish for file:check_access/2 still stays :-) We often check read/write access to files (logs, credentials etc) but we are not interested in other metadata for those files. Probably it should be a matter of another PR though.

The problem with file:check_access/2 is that on Windows there is no equivilant check that makes sense (that we know of).