3 ms·
> fail to work in settings where /proc is not available The chmod problem aside, how does this not seem crazy? Why in the world should a hard-coded filesystem
by dataflow 3y ago
> fail to work in settings where /proc is not available
The chmod problem aside, how does this not seem crazy? Why in the world should a hard-coded filesystem path (let alone a particular mount point) be necessary to access some process-related kernel features? Would the sky fall down if they provided a non-filesystem way (read: a syscall...) to access useful functionality like all the other apparently-uncool kernels do?
- themoonisachees 3y agoRealistically? In all environments where you would want to do file access control, you would have /proc. I agree that it's kind of dumb to require it, but the reality of it is that nobody wants to make it work bad enough to fix it.
- dataflow 3y agoproc has way more in it than just proc/fd though?
- Karellen 3y ago> how does this not seem crazy? Yeah, it kind of is. But it's the best solution that works in the most cases, and fails in the least bad ways possible, given the constraints available. It's a hack, and technical debt. Sometimes that happens. Fixing it properly by implementing `fchmodat2()` is (finally) going back and paying down that technical debt. If it didn't seem crazy to someone, then probably no-one would have bothered addressing it.
- dataflow 3y agoIt's great that they added 1 syscall after so many years to address one corner case, but at this rate humanity will be extinct by the time they get halfway through. You'd think they could provide a workaround for the whole thing in the interim by just providing a special open function (procfs_open?) that just opens the proc directory without caring if/where it's mounted?
- deleted 3y ago[deleted]