[amluto]

It’s not just /proc/sys/mem. One could also modify executable files and cause all manner of other mayhem. At the end of they, if you have access to all ambient privileges available to your process, you can use them. Trying to specifically block memory safety violations would be a bit odd.

[Joker_vD]

> One could also modify executable files

ETXTBSY.

[amluto]

Not if they’re not running or if you replace them outright. So you can rename a garbage file over your main executable, exec yourself, and segfault. Is that memory unsafety?

How about ptracing yourself?

How about undervolting your CPU such that it malfunctions?

How about running your program off a FUSE filesystem that changes the contents out from under it?

How about editing the raw block device you’re running from?

How about modifying /dev/mem on older systems that allow that?

This particular rabbit hole is extremely deep, and I don’t think it’s practical to address it for real short of making a real security model for what running code may and may not to do the rest of the world. (I think doing that is an extremely worthwhile endeavor, but disallowing opening specific files won’t be part of it.)

[jonathrg]

In case anyone else was wondering if this was an acronym for an aphorism (like YAGNI), this is an error code (error text busy). And 'text' refers to the executable