Re: Changes to LSM phase 1 for audit.

chrisat_private

* Greg KH (gregat_private) wrote:
> 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 :)

typedef struct file * filp;

no, this is not true.  a descriptor does not uniquely identify a filp.
each open(2) will give you a file descriptor that points to a unique filp.
but, if you dup(), dup2() or fcntl(F_DUPFD) you can have multiple
descriptors referncing the same filp.

> > 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.

as i mentioned before, the fd is critical in at least one case:
fnctl(F_SETFD) or close_on_exec.  it is possible to have the a descriptor
that references the same filp, but they could have different close_on_exec
values.  so i can see it would be useful in at least that case.

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module