The kdbuswreck

Posted Apr 25, 2015 0:08 UTC (Sat) by kentonv (subscriber, #92073)
In reply to: The kdbuswreck by cesarb
Parent article: The kdbuswreck

Hmm, I think the main thing I'm worried about is not that capability FDs will be indiscriminately closed by existing tools (e.g. ones that explicitly close all FDs above 2 before exec), but rather the opposite: that it will be too easy to inherit capabilities when you don't intend to. That gets back to "ambient authority". Really, the capability should only be passed on to processes that need it. This means that intermediate apps (e.g. shells) need good ways to explicitly control when to pass capability FDs without getting overly verbose. Today's shells are actually not that bad at this, but some further improvement would probably be desirable, and desktop environments are another matter.

I think putting capabilities in a separate table would actually be a step backwards, in that all the existing tools that work with FDs would not work with these. That means you couldn't manipulate them in bash, you couldn't pass them over unix domain sockets, etc.

The kdbuswreck

Posted Apr 25, 2015 0:52 UTC (Sat) by cesarb (subscriber, #6266) [Link]

> I think putting capabilities in a separate table would actually be a step backwards, in that all the existing tools that work with FDs would not work with these. That means you couldn't manipulate them in bash, you couldn't pass them over unix domain sockets, etc.

They are still FDs, just stashed away in a "shadow" table. They could be easily passed over unix domain sockets (dup3 to the normal table, send it over, and close the copy in the normal table).

I agree that hiding them makes them impossible to manipulate with unmodified tools like bash, but that's sort of the point of the thought experiment: a way to add capability FDs without interfering with anything which doesn't use them, thus allowing for gradual introduction of the feature. It's only a thought experiment, after all.

There's precedent for that sort of trickery: I recall seeing some discussion here on LWN about a way to allow libraries to open FDs without interfering with or being interfered by the application (IIRC, the proposal was to stash them as directly-allocated high-numbered FDs, instead of using the lowest available slot).