I submitted the first patch for this way back in 2012. It received a couple positive comments but was ignored by the maintainers, as was my followup[1]. William Orr made another unsuccessful attempt in 2015, and then there were the attempts by Greg Kurz in 2017 and Rich Felker in 2020 which were mentioned in the article.
Absolutely nuts that it took 5 attempts over 11 years to get in a <50 line patch that adds support for flags specified by POSIX.
> 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?
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.
It'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?
Absolutely nuts that it took 5 attempts over 11 years to get in a <50 line patch that adds support for flags specified by POSIX.
[1] https://lkml.kernel.org/lkml/20140121105735.56cc4ec41a6f2071...