check_syscall(): turn internal sandbox violation into denywrite

In #590084 test suite performed to list files in a deleted directory:
    $ sandbox 'mkdir /tmp/zzz; cd /tmp/zzz; rmdir /tmp/zzz; ls'
     * sandbox-2.18/libsandbox/libsandbox.c:check_syscall():974: failure (No such file or directory):
     * ISE: opendir(.)
    abs_path: (null)
    res_path: (null)

Another reproducer is to create file outside deleted directory relative
to that directory:
    $ sandbox 'mkdir /tmp/zzz; cd /tmp/zzz; rmdir /tmp/zzz; touch ../foo'
     * sandbox-2.18/libsandbox/libsandbox.c:check_syscall():974: failure (No such file or directory):
     * ISE: open_wr(../foo)
    abs_path: (null)
    res_path: (null)

sandbox can't validate safety of any of these operations as kernel does not
provide a mechanism to resolve '.' back to an absolute path.

As it's a rare condition let's turn it into a sandbox violation instead
of internal sandbox error and link to the bug with details in the error message.

Report after the change looks like:
    $ ./sandbox.sh 'mkdir /tmp/zzz; cd /tmp/zzz; rmdir /tmp/zzz; touch ../foo'
     * ACCESS DENIED:  open_wr:      '../foo' (from deleted directory, see https://bugs.gentoo.org/590084)
     * ACCESS DENIED:  utimensat:    '../foo' (from deleted directory, see https://bugs.gentoo.org/590084)
    touch: cannot touch '../foo': Permission denied

Reported-by: Mike Gilbert
Bug: https://bugs.gentoo.org/590084
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Michał Górny <mgorny@gentoo.org>

0 files changed, 0 insertions, 0 deletions