Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> should be used. Someone or something caused the event. It can > >> be important who it was. > > The kernel's normal security model means that you should be able to > > e.g. accept FDs that random processes send you and perform > > read()/write() calls on them without acting as a subject in any > > security checks; let alone close(). > > Passed file descriptors are an anomaly in the security model > that (in this developer's opinion) should have never been > included. More than one of the "B" level UNIX systems disabled > them outright. Considering further on this, I think the only way to implement what you're suggesting is to add a field to struct file to record the last fputter's creds as the procedure of fputting is offloaded to a workqueue. Note that's last fputter, not the last closer, as we don't track the number of open fds linked to a file struct. In the case of AF_UNIX sockets that contain in-the-process-of-being-passed fds at the time of closure, this is further complicated by the socket fput being achieved in the work item - thereby adding layers of indirection. It might be possible to replace f_cred rather than adding a new field, but that might get used somewhere after that point. Note also that fsnotify_close() doesn't appear to use the last fputter's path since it's not available if called from deferred fput. David
