Re: 'port build' is getting EPERM from access(2) on /var/tmp
On Sat, May 24, 2014 at 10:18:12AM +1000, Joshua Root wrote:
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.
That would explain it.
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
Oh, I see, that * was just meant as a wildcard expression.
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,
That was covered in my base note, access(/var/tmp, W_OK).
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.
I suspect that's not going to work well since the configure script
is looking for a writable tmp directory to compile into the program
for when it is run by the user after installation.
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.
Ah, ok.
- Josh
Quentin
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: 'port build' is getting EPERM from access(2) on /var/tmp
On 2014-5-25 09:21 , Quentin Barnes wrote: On Sat, May 24, 2014 at 10:18:12AM +1000, Joshua Root wrote: I'm not sure what exact syscalls test -w uses, That was covered in my base note, access(/var/tmp, W_OK). but possibly allowing file-write-data on /var/tmp would be correct and allow it to succeed. Well, try this: Index: src/port1.0/portsandbox.tcl === --- src/port1.0/portsandbox.tcl (revision 120356) +++ src/port1.0/portsandbox.tcl (working copy) @@ -89,6 +89,7 @@ (allow file-write-data (literal \/dev/null\) (literal \/dev/zero\) \ (literal \/dev/dtracehelper\) (literal \/dev/tty\) \ (literal \/dev/stdin\) (literal \/dev/stdout\) (literal \/dev/stderr\) \ +(regex #\^(/private)?(/var)?/tmp\$\) \ (regex #\^/dev/fd/\)) (allow file-write* \ (regex #\^(/private)?(/var)?/tmp/\ #\^(/private)?/var/folders/\)) But it wouldn't hurt for the script to try $TMPDIR as well. I suspect that's not going to work well since the configure script is looking for a writable tmp directory to compile into the program for when it is run by the user after installation. Ah, OK. The right thing would be for the program to look at TMPDIR at runtime then. I guess it would still want a fallback in case TMPDIR isn't set, so the configure script should provide a way to specify one directly in case it can't find one automatically. You can probably override some autoconf var on the command line without even modifying the script. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: 'port build' is getting EPERM from access(2) on /var/tmp
On Tue, May 13, 2014 at 05:34:31AM +1000, Joshua Root wrote:
On 2014-5-13 05:01 , Clemens Lang wrote:
Hi,
Please keep the conversation on the list so others with the same problem
can follow.
Yes! The `sandbox_enable no' hack worked around the problem.
Can you reproduce the problem by creating a fake package and trying the
test -w /var/tmp?
Yes, I can reproduce this with a minimal example:
PortSystem 1.0
nametest
version 1.0
maintainers cal
categories test
description Description
long_descriptionLongDescription
platforms darwin
homepageHomepage
distfiles
configure {
system test -w /var/tmp
system test -w /var/tmp/
system test -w /var/tmp/foo
}
I'm not sure why it fails for /var/tmp/foo, though – my understanding is it
should work.
You would have to create foo first.
What else would you like me to try?
I've CC'd somebody more knowledgeable on sandboxing than I am. Joshua, any
idea what's wrong here or is this expected behavior?
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.
Could you explain what you meant by the *?
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?
Can the sandbox config be changed so it creates a writable scratch
tmp directory and then transforms /var/tmp paths to point to it?
- Josh
Quentin
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: 'port build' is getting EPERM from access(2) on /var/tmp
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
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: 'port build' is getting EPERM from access(2) on /var/tmp
Hi,
Please keep the conversation on the list so others with the same problem
can follow.
Yes! The `sandbox_enable no' hack worked around the problem.
Can you reproduce the problem by creating a fake package and trying the
test -w /var/tmp?
Yes, I can reproduce this with a minimal example:
PortSystem 1.0
nametest
version 1.0
maintainers cal
categories test
description Description
long_descriptionLongDescription
platforms darwin
homepageHomepage
distfiles
configure {
system test -w /var/tmp
system test -w /var/tmp/
system test -w /var/tmp/foo
}
I'm not sure why it fails for /var/tmp/foo, though – my understanding is it
should work.
What else would you like me to try?
I've CC'd somebody more knowledgeable on sandboxing than I am. Joshua, any
idea what's wrong here or is this expected behavior?
--
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: 'port build' is getting EPERM from access(2) on /var/tmp
On 2014-5-13 05:01 , Clemens Lang wrote:
Hi,
Please keep the conversation on the list so others with the same problem
can follow.
Yes! The `sandbox_enable no' hack worked around the problem.
Can you reproduce the problem by creating a fake package and trying the
test -w /var/tmp?
Yes, I can reproduce this with a minimal example:
PortSystem 1.0
nametest
version 1.0
maintainers cal
categories test
description Description
long_descriptionLongDescription
platforms darwin
homepageHomepage
distfiles
configure {
system test -w /var/tmp
system test -w /var/tmp/
system test -w /var/tmp/foo
}
I'm not sure why it fails for /var/tmp/foo, though – my understanding is it
should work.
You would have to create foo first.
What else would you like me to try?
I've CC'd somebody more knowledgeable on sandboxing than I am. Joshua, any
idea what's wrong here or is this expected behavior?
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.
- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
