On 02/10/17 08:13 AM, Carlos E. R. wrote:
Irrelevant. That's not the problem or question, but why some program try to create executables there, and why does it crash when it gets denied.
I agree that caches should be noexec, but I think this is a heavy handed way of working and has nothing to do with solving the problem of that WHAT and the WHY. Yes, it is reminiscent of early Microsoft. But I'm not a coder and I'm not a forensic specialist, but I'd still approach this by running the program under the debugger to see where it crashed. At least it would tell me where it crashed, if it was in the code body or a library, and what it was trying to access or set up when that happened. The I would have something specific to bring to the attention of the list and the developer, a SPECIFIC bug to report. I agree with you when you say in an earlier post that it is about security. If we didn't have other tools I'd be investigating doing a lot of binding of directories to make them read only and/or no-exec. But the /dev/shm or as tis example does it, tmpfs also makes clear that those directories are flushed. I can understand flushing /tmp. I don't think flushing some caches is a good idea. For example under /var/cache/zypp/solv there are keys and sat-solver files. If you flush those, you need to rebuild them all from scratch when you 'zypper [d]up' or the YaST equivalent. Big OUCH. You want a nodev,nosuid,noexec there? Good. Fine. Do it with a Bind. The point I'm making here, having to make as you've done the switcheroo between your last two posts between solely saying "security" and solely saying it's an execution bug, is that all this is using a blunderbuss to address a mosquito. Yes, the mosquito is pernicious, but the blunderbuss is causing collateral damage that is not necessary. -- have both /tmp and /var/tmp as tmps is too heavy handed, there is no persistent scratch namespace -- purging caches is counter-productive it defeats the purpose of caches and impacts performance when they need to be rebuilt -- having /run as a tmpfs, whcih is the norm, means that everything under it such as /run/lock, is already in the tmpfs, so no need to duplicate that -- having established /run as a a tmpfs many things can be done simply by linking to is. You can see examples of this in /usr/lib/udev/rules.d -- most of these items would be better done as links, symlinks or as mount-binds. It would put less demand on the shared memory system and swap, be better handled by the kernel (I'll detail that if you want) -- why aren't you using apparmor? -- why aren't you suing the regular file access controls? A principle of debugging is 'wolf fencing'. That is, setting up a boundary (fence) and determining which side of it the bug (wolf) is on it. Right now there s a lot going on here. We can't know if problem is is a result of the noexec restriction or, perhaps, it being a problem with the application trying to create a socket (rather than a device) on a nodev? Yes, I agree, there are proper places to create public and private sockets, and cache directories should, perhaps, not be those. However I can think of arguments where they should be, but that's another matter. I know I can create a pipe on a nodev mounted /tmp, but a socket? -- "Unsustainable" is the new go-to term for "don't do something we don't like and don't ask for an actual reason." -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org