Editing File descriptor (section)

==File descriptors as capabilities==
Unix file descriptors behave in many ways as [[Capability-based security|capabilities]].  They can be passed between processes across [[Unix domain socket]]s using the <code>[[sendmsg]]()</code> system call. Note, however, that what is actually passed is a reference to an "open file description" that has mutable state (the file offset, and the file status and access flags). This complicates the secure use of file descriptors as capabilities, since when programs share access to the same open file description, they can interfere with each other's use of it by changing its offset or whether it is blocking or non-blocking, for example.<ref>{{cite web
| url=http://www.eros-os.org/pipermail/cap-talk/2009-February/012137.html
| title=Building a bridge: library API's and file descriptors?
| first=Marcus
| last=Brinkmann
| date=2009-02-04
| work=cap-talk
| access-date=2017-09-21
| archive-url=https://archive.today/20120730163337/http://www.eros-os.org/pipermail/cap-talk/2009-February/012137.html
| archive-date=2012-07-30
| url-status=dead
}}</ref><ref>{{cite web
| url=http://jdebp.eu/FGA/dont-set-shared-file-descriptors-to-non-blocking-mode.html
| title=Don't set shared file descriptors to non-blocking I/O mode.
| first=Jonathan
| last=de Boyne Pollard
| year=2007
| access-date=2017-09-21}}</ref> In operating systems that are specifically designed as capability systems, there is very rarely any mutable state associated with a capability itself.

A Unix process' file descriptor table is an example of a [[C-list (computer security)|C-list]].