> > > 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 :-) -serge _______________________________________________ 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 : Thu Jul 19 2001 - 13:02:13 PDT