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 abilit
Just ENOENT? What about…
… ENOTDIR?
… ENAMETOOLONG?
… ELOOP?
… EFAULT?
… EIO? (That one’s actually Heisenberg.)
This approach also will catastrophically fail if new errnos added, or if
an OS has defined its own custom ones.
Nope, not going there. Do not break stat(), period.
--
You receive
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, t
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.
Matching
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
St
“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
Public bug reported:
>From "man 1 test"
NAME
test - check file types and compare values
DESCRIPTION
Exit with the status determined by EXPRESSION.
[deleted]
-e FILE
FILE exists
When "test -e" is called, it is intended to determine the existence or
no
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 126
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 are
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:
misle
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 the
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 co
Hmm. In the case Nick posted, it can “see” the file (find it) but not
read it.
In the other case, an intermediate directory is not accessible.
This has been so since pdksh times, and I think some code later on
checks for ENOENT, so just passing through the errno may introduce other
problems.
The
13 matches
Mail list logo