'port build' is getting EPERM from access(2) on "/var/tmp"

[Joshua Root]

On 2014-5-24 03:19 , Quentin Barnes wrote:
> On Tue, May 13, 2014 at 05:34:31AM +1000, Joshua Root wrote:
>> We do exclude /var/tmp itself with the regex we use. We certainly don't
>> want to allow file-write* on it, but possibly one of the subsets could
>> be added safely.
> 
> Obviously, in the sandbox /var/tmp can be written to since I can
> touch a file underneath it, so I'm not sure I follow your last point.

I believe the checks operate purely on the (normalised) path. So when we
say:

(allow file-write* \
(regex #\"^(/private)?(/var)?/tmp/\" #\"^(/private)?/var/folders/\"))

operations that specify /var/tmp/foo as their target will be allowed,
but not ones that specify /var/tmp.

> Could you explain what you meant by the "*"?

The complete list of operations covered by file-write* is, to the best
of my knowledge:

file-write-data
file-write-flags
file-write-mode
file-write-mount
file-write-owner
file-write-setugid
file-write-times
file-write-unmount
file-write-xattr

> The configure script is searching a potential list for a valid
> directory on the system that it has write access to for its scratch
> files.  It iterates using a "if test -d $i -a -w $i; then ..." test.
> 
> What should be the most appropriate, long-term fix?  Change the
> sandbox config in some way?  Patch the configure script?

I'm not sure what exact syscalls test -w uses, but possibly allowing
file-write-data on /var/tmp would be correct and allow it to succeed.

But it wouldn't hurt for the script to try $TMPDIR as well.

> Can the sandbox config be changed so it creates a writable scratch
> tmp directory and then transforms /var/tmp paths to point to it?

No, all sandboxing can do is deny access to stuff. We do already set
TMPDIR to "${workpath}/.tmp".

- Josh