Bugzilla

> Do you have a backtrace here? The log you give above is for another file.

Have attached the 2 logs
- mach run with the current policy unchanged (i.e. no crash instead) - this allows the open of /dev/null 
- mach run with the crash instead on /dev/null policy - this crashed on the open of /dev/null 

In both logs, you can look for the string "!!!!!!!!!About to call the Graphite setup" which is printed just prior to the call to open "/dev/null". If the call to open /dev/null is successful in rust, the rust code prints "!!!!!!!!!!!!!!!!!!!!/dev/null opennig was ok" - this is present in the first log.

> /dev/null is being accessed (and to get rid of it again, potentially) in another bug

Actually, we can't get rid of this. My original confusion was actually because I thought I did not need a policy for open... I had thought that I needed a policy only on read and write. However, given that I need a policy for open as well, the only solution here is to add /dev/null

> Do you have a backtrace here? The log you give above is for another file.

Have attached the 2 logs
- mach run with the current policy unchanged (i.e. no crash instead) - this allows the open of /dev/null 
- mach run with the crash instead on /dev/null policy - this crashed on the open of /dev/null 

In both logs, you can look for the string "!!!!!!!!!About to call the Graphite setup" which is printed just prior to the call to open "/dev/null". If the call to open /dev/null is successful in rust, the rust code prints "!!!!!!!!!!!!!!!!!!!!/dev/null opennig was ok" - this is present in the first log.

> /dev/null is being accessed (and to get rid of it again, potentially) in another bug

Actually, we can't get rid of this for 2 reasons...
1) My original confusion was actually because I thought I did not need a policy for open... I had thought that I needed a policy only on read and write. However, given that I need a policy for open as well, the only solution here is to add /dev/null
2) We also do need write access for the library sandboxing use case. While we initially were Ok with redirecting output from the sandboxed library to the terminal, this is actually something that needs be context dependent or configurable... If we choose to disallow output to the terminal based on the config, this would mean redirecting all writes to /dev/null...

> Do you have a backtrace here? The log you give above is for another file.

Have attached the 2 logs
- mach run with the current policy unchanged (i.e. no crash instead) - this allows the open of /dev/null 
- mach run with the crash instead on /dev/null policy - this crashed on the open of /dev/null 

In both logs, you can look for the string "!!!!!!!!!About to call the Graphite setup" which is printed just prior to the call to open "/dev/null". If the call to open /dev/null is successful in rust, the rust code prints "!!!!!!!!!!!!!!!!!!!!/dev/null opennig was ok" - this is present in the first log.

> /dev/null is being accessed (and to get rid of it again, potentially) in another bug

Actually, we can't get rid of this for 2 reasons...
1) My original confusion was actually because I thought I did not need a policy for open... I had thought that I needed a policy only on read and write. However, given that I need a policy for open as well, the only solution here is to add /dev/null
2) We also do need write access for the library sandboxing use case. While we initially were Ok with redirecting output from the sandboxed library to the terminal, we subsequently found this is actually something that needs be context dependent or configurable... If we choose to disallow output to the terminal based on the config, this would mean redirecting all writes to /dev/null...