I changed the error message, as indicated.
** Changed in: mksh
Status: Opinion => Fix Released
--
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
To be clear, the current implementation of using stat(), reading the
permissions, then later exec()ing is subject to the same race conditions
described in the access() man page. Just because stat() doesn't include
these warnings in the man page shouldn't be interpreted that the current
usage is
I vaguely recall something about access() succeeding for file foo when
foo.exe exists on some platforms, or the other way round, and that the
modes are also not always correct. The manpage supports the latter…
Even if a process has appropriate privileges and indicates success for
X_OK,
“5) A failure of the stat() system call is not an accurate indicator of
the exec()-ability of the file. The only way to determine if a file is
executable is to execute it.”
This is not generally true. We need to check for +x, and there was
something with strange operating systems, *and* the shell
Are you referring to Posix 1003.1 section "C.2.8.2 Exit Status for
Commands"?
Historical shells make the distinction between ‘‘utility not found’’ and
‘‘utility found but cannot execute’’ in their error messages. By specifying
two seldomly used exit status values for these cases, 127 and
stat() must always succeed, because we must check that the executable
bits are set before accepting the file as command (if not for anything
else, then because POSIX was changed to demand distinguishing $? between
126 and 127 for these cases).
--
You received this bug notification because you
What do you think of “not found or inaccessible”? (I hope I spelt that
right.)
--
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:
Additionally, this behavior also causes problems where the security
policy writer, for whatever reason, wants to allow a file to be executed
but disallow stat() operations. This could occur, for example, in high
sensitivity environments where leaking metadata (size, last update time,
etc) about
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
No.
When you do
mksh -c /tmp/d/f
you ask mksh to find it as a command. The “not found” error message there is
more general; for example, it also happens if the interpreter is not found:
print '#!/nonexistent-int' >/tmp/ff
chmod 755 /tmp/ff
mksh -c /tmp/ff
(This even results in
10 matches
Mail list logo
