Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!bloom-beacon!hstbme.mit.edu!scs From: scs@hstbme.mit.edu (Steve Summit) Newsgroups: comp.unix.wizards Subject: File daemons (was: How do I detect who and when A file gets accessed ?) Message-ID: <14609@bloom-beacon.MIT.EDU> Date: 24 Sep 89 23:40:04 GMT References:Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Distribution: na Lines: 33 The obvious fully-general solution is to allow arbitrary functions to be attached to files, to perform any kind of authentication checking or audit trails that the file's owner might desire. How much work (if any) has been done on implementing such a scheme under Unix? Conventional Unix st_mode permissions are usually found to be insufficient for doing really seriously security-conscious work, but I have heard that some "secure Unix" standardization effort or another has merely adopted ACL's which, while obviously more flexible than 9 bits, are essentially just more of the same, namely a static, tabular representation of who can do what, without the radically greater level of generality that an algorithmic permission option could afford. There are certainly some questions to be answered about such "file daemons:" who do they run as, the attempting accessor or the file owner? (The latter, I think.) What per-file data can the daemon function use? (It potentially needs arbitrary storage, attached to the inode somehow, sort of like the file contents itself but "out of band" with respect to it.) Note that ACL's could be easily implemented under a "file daemon" scheme (this is one indication of its superior generality): you could write an ACL-checking daemon once, and attach it to any file, storing the ACL itself in the per-file "out of band" data. I suspect that this is one of those areas where the extra generality is expensive enough to implement, but needed in such a small percentages of cases, that it usually isn't worth doing. Steve Summit scs@adam.pika.mit.edu (alternate) scs@hstbme.mit.edu