Re: Names vs. Inodes

chrisat_private

* Serge E. Hallyn (hallynat_private) wrote:
> > > > If we can't build a practical means to reconstruct the path name from the
> > > > inode, we may want to put the name hook back in again.  We feel that it is
> 
> And since it's starting to sound like several people might need this,
> we should seriously consider doing so.
> 
> It's starting to sound as though we really should have had a meeting
> after the last BOF for the pathname-based approach people to talk,
> and figure out what we all needed.  I should have recommended that a
> little louder I guess.
> 
> > > > reasonable for an access control module to want to know the name of a file
> > > > being opened, and LSM should provide *some* way of determining that name.
> > >
> > > So what would this mean for Serge's new hooks?
> > I don't know.  I was troubled when they went in, because we had not yet
> > resolved whether there was an alternate means to reconstruct the requesting
> > process's view of the name of the requested file.  We still don't know if its
> > possible.  Serge has shared some code with Chris, which he is evaluating.
> 
> Judging by what I've heard here today, what I'm doing is nothing at all like
> what you need.  On the other hand, neither is attach_pathlabel or whatever
> it was called, because it simply gives you a chance to label an inode based
> on pathnames.  When you get to permission(), you still have only the inode
> and the label you gave it to make your decision, but that label was attached
> by whoever first (or, if you're hunting for really bad performance, last)
> looked up a pathname for that inode.  Sure, I guess you could make your
> inode->i_security pointer point to an array indexed by PID  :-)

this is the crux of the problem...if we could get dentry and vfsmount in
permission, then we'd have inode and pathname.

-chris

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