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
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:
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
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
“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
My system, the Android operating system, uses SELinux to disallow stat()
for a large number of files and directories. This prevents side channel
leakage between various untrustworthy processes, helping preserve user
privacy and preserve the confidentiality of the system. For good reason,
the
If you insist on stat(), then it should be fairly straight forward to
check errno.
File exists if stat() returns success, *or* if stat() returns failure
and errno != ENOENT.
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
On unix. test whether a file exists is done using stat. access is not
portable and buggy on many platforms.
Honestly, write your security policies to not block stat. I’m not even
going to bother with this one.
** Changed in: mksh
Importance: Undecided => Wishlist
** Changed in: mksh
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,
10 matches
Mail list logo
