On Fri, Mar 11, 2022 at 05:15:01PM -0500, Paul Moore wrote: > The silence on this has been deafening :/ No thoughts on fixing, or > not fixing OPEN_FMODE(), Al? > > At this point I have to assume OPEN_FMODE() isn't changing so I'm > going to go ahead with moving SELinux over to file::f_flags. Once > I've got something working I'll CC the LSM list on the patches in case > the other LSMs want to do something similar. Full disclosure, that > might not happen until early-to-mid next week due to the weekend, new > kernel expected on Sunday, etc. ENOBUG. The primary user of that is fdutils; they wanted to be able to issue ioctls on a floppy disk drive, with no disk inserted. Or with a disk that has weird formatting (as the matter of fact, some of those ioctls are precisely "use such-and-such weird format"). A cleaner solution would be to have a separate device node (or sysfs file, or...) for that kind of OOB stuff. However, that's not how it had been done way back when, and we are stuck with the existing ABI. Namely, "have the lower two bits of flags both set" for "open for ioctls only; require MAY_READ|MAY_WRITE on device node, allow neither read() nor write() on that descriptor". I'm not sure if anyone _uses_ fdutils these days. OTOH, you never know what kind of weird setups gets used, and qemu has floppy emulation, so we can't even go for "no floppy drive is going to be in working condition nowadays". So I'm afraid that this ABI is going to stay ;-/ It's a long-standing wart, from at least '94 if not earlier, it's documented (open(2)) and it's used by a package that is shipped at least by debian and ubuntu. And it's certainly *not* the kind of code anyone sane would want to migrate to a replacement ABI, no matter how nice - look through the list of utilities in there and imagine what the testing for regressions would feel like.
