* Chris Evans (chrisat_private) wrote: > > Hi, > > I'm not so sure you want to add special cased code in mmap that "knows" > MAP_SHARED, PROT_WRITE && !MAP_ANON is equivalent to a write operation. It's kind of already there isn't it? The check !(file->f_mode & FMODE_WRITE). Not that that makes it right to add this check... > The "pushing hooks to be as late as possible" sounds like it may be the > way forward, but wouldn't that mean looking at "struct > address_space_operations": readpage, writepage? Thanks, I hadn't taken the time to really look at this yet. My only concern is overhead. Isn't readpage going to get called _a lot_ when reading a file? > Unfortunately, (and ICBW), this doesn't handle non-pagecache entities like > block/character devices. Or directories. Ho hum. Ugh! Back to the page cache/buffer cache problem. If we are lucky we can punt on some of these issues. AFAIU, Linus wants to push block i/o to the page cache for 2.5 (and this project is targeting 2.5...;-) > > BTW, I don't think your current hooks would catch a sendfile() operation, > which IIRC goes through the unhooked readpage() rather than the hooked > read() or mmap(). I think you are right. We mean to catch sendfile (i.e. it's on the hotlist), but it just hasn't been added yet. > > In fact is there much value to attempting to hook read()/write() > operations at all? Shouldn't access be controlled at open() time? (or > bind() time for sockets). Something like MAC should work with just that. Heh...as far as the list archives go, this is akin to a can of worms. ;-) Basically, because you can pass open file descriptors between processes (via fork or sendmsg/recvmsg for example) you can't exclusively rely on open() (and bind() is not "required" for socket communication). -chris _______________________________________________ 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 : Mon May 14 2001 - 21:07:39 PDT