In the SELinux case that Elliott pointed to in the initial bug report,
mksh can also "see" the file (eg, stat() returns EACCES, indicating the
file exists but security policy disallows stat() operations). Yet "not
found" is emitted by mksh vs (the IMHO more correct) "Permission
denied". The mksh code assumes any stat() failure is due to the file not
existing vs other causes. Unfortunately, this error condition can only
be replicated using one of the available Linux Mandatory Access Control
systems such as SELinux, Smack, AppArmor, or Tomoyo.

Similarly, in the following scenerio, mksh can "see" the asdf command,
but still returns "not found", when the command clearly exists but is
malformed.

  nnk@nnk0:/tmp$ mkdir d
  nnk@nnk0:/tmp$ ln -s ../asdf d/asdf
  nnk@nnk0:/tmp$ ln -s d/asdf asdf
  nnk@nnk0:/tmp$ ls -la d/asdf asdf
  lrwxrwxrwx 1 nnk nnk 6 Feb 27 09:27 asdf -> d/asdf
  lrwxrwxrwx 1 nnk nnk 7 Feb 27 09:27 d/asdf -> ../asdf
  nnk@nnk0:/tmp$ mksh -c /tmp/asdf
  mksh: /tmp/asdf: not found

Bash provides a more accurate error message in this case:

  nnk@nnk0:/tmp$ bash -c /tmp/asdf
  bash: /tmp/asdf: Too many levels of symbolic links

This is particularly problematic for interactive shells, where the lack
of accurate error messages inhibits end user understanding of the error
conditions.

  nnk@nnk0:/tmp$ mksh
  $ /tmp/asdf
  mksh: /tmp/asdf: not found
  $ ls -la /tmp/asdf
  lrwxrwxrwx 1 nnk nnk 6 Feb 27 09:27 /tmp/asdf -> d/asdf
  $ mkdir d2
  $ touch d2/a2
  $ chmod 000 ./d2
  $ /tmp/d2/a2
  mksh: /tmp/d2/a2: not found

Can you elaborate on the statement that "passing through the errno may
introduce other problems"? What other problems are you concerned about?
The statement feels unactionable.

IMHO, changing "not found" to a more generic string, without other
changes, would not improve end user understandability.

Thank you for your continued dialog on this issue.

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1817789

Title:
  misleading error message for SELinux denials

Status in mksh:
  Opinion

Bug description:
  Given a stat(2) failure caused by an SELinux denial (rather than a
  stat(2) success and an access(2) failure, as with a regular `chmod
  a-x` failure), mksh reports "not found" rather than the more correct
  "Permission denied".

  Expected:
  * Permission Denied error message

  Actual:

    $ sh -c /system/bin/vold
    sh: /system/bin/vold: not found

    "not found" error message.

  
  here's the behind-the-scenes SELinux denial:

  02-25 22:37:11.023  4571  4571 W sh      : type=1400 audit(0.0:347):
  avc: denied { getattr } for path="/system/bin/vold" dev="dm-0" ino=717
  scontext=u:r:shell:s0 tcontext=u:object_r:vold_exec:s0 tclass=file
  permissive=0

  
  here's what strace says happened:

  newfstatat(AT_FDCWD, "/system/bin/vold", 0x7ffcc3ef20, 0) = -1 EACCES 
(Permission denied)
  write(2, "/system/bin/sh: /system/bin/vold"..., 44/system/bin/sh: 
/system/bin/vold: not found
  ) = 44

  versus the normal `chmod a-x` case where stat succeeds but access
  fails:

  newfstatat(AT_FDCWD, "/data/local/tmp/date2", {st_mode=S_IFREG|0644, 
st_size=482560, ...}, 0) = 0
  faccessat(AT_FDCWD, "/data/local/tmp/date2", X_OK) = -1 EACCES (Permission 
denied)
  write(2, "sh: /data/local/tmp/date2: can't"..., 60sh: /data/local/tmp/date2: 
can't execute: Permission denied
  ) = 60

  
  this patch fixes the issue:

  ```
  diff --git a/src/exec.c b/src/exec.c
  index 8330174..3f6d876 100644
  --- a/src/exec.c
  +++ b/src/exec.c
  @@ -1279,8 +1279,8 @@ search_access(const char *fn, int mode)
          struct stat sb;
   
          if (stat(fn, &sb) < 0)
  -               /* file does not exist */
  -               return (ENOENT);
  +               /* file may or may not exist: check errno */
  +               return errno;
          /* LINTED use of access */
          if (access(fn, mode) < 0) {
                  /* file exists, but we can't access it */
  ```

  i don't know if you want to elaborate further in the comment along the
  lines of "...for example, an SELinux denial may mean that we get
  EACCES here, or if the file doesn't exist and we're allowed to know
  that, we'll get ENOENT".

  
  result with patch:

  $ sh -c /system/bin/vold
  sh: /system/bin/vold: can't execute: Permission denied

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1817789/+subscriptions

Reply via email to