On Tue, Jul 17, 2001 at 03:10:12PM -0400, Stephen Smalley wrote: > > Although I'm not a fan of passing the fd, it isn't clear to me that > SGI can readily obtain the fd from the 'struct file *'. Wouldn't they > have to search through the file descriptor table for a match, yielding > race conditions? And what if multiple descriptors referenced the same > struct file? I suppose that may not be important if they just want a > handle for the file. The fd can be reconstructed by doing the opposite of the fget() call. And yes, you need to do the proper locking when searching the file descriptor list :) > In any event, it would be helpful if the SGI folks could explain > why they want a fd for each hook to which they've added such a > parameter and could make the case that the 'struct file' is inadequate > for providing equivalent functionality. Why audit the fd instead > of a pathname generated from the struct file? If you are simply > looking for a small handle to reference a given file for numerous audit > records, you can always create and maintain your own mapping from integer > handles to files without needing to deal with the non-persistent > per-process fd values. I agree. The fd is an arbitrary number. The struct file is so much more authoritative. > Do you know why "some people" will have a problem with this change? > It doesn't seem like it should affect any of us with restrictive access > control modules, and it does provide desirable support for MAC > policies. The parties in question have said they will post later on today about this issue. If not, they must not mind :) thanks, greg k-h _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Jul 17 2001 - 13:39:27 PDT