Serge E. Hallyn wrote: >Not sure if I understand you correctly here, but if all i have is the >inode and relative pathname (ie, inode for "/var/spool/mail", and >name "hallyn"), that is obviously insufficient, since that prevents >me assigning the same typename at points in otherwise distinct fs >subtrees. For instance, for whatever reason, I might have /var/spool/mail >and /usr/spool/mail as actually different directories, same security label, >but want to assign a different security label to "hallyn" under each. Could you elaborate? Are you saying that /var/spool/mail and /usr/spool/mail refer to the same inode, but you want different semantics depending on which filename is used to refer to the directory? I don't see how you can make this compatible with Unix semantics, so maybe this isn't what you're referring to. Or are you saying that they refer to two different inodes, but that with your current choice of the space of possible label, these two inodes might get assigned the same label even though you want /usr/spool/mail/hallyn to have a different label from /var/spool/mail/hallyn? In this case, have you considered the possibility of enlarging the space of possible labels to fix this problem? In other words, include another field in the security object of each directory inode with all the information needed to know how to assign labels to new files created under that directory. This seems like it would likely form a clean solution to the problem for many natural policies, but since I don't know what policy you are trying to enforce, I don't know for sure whether it would apply to your case. Did I understand correctly what you are trying to accomplish? _______________________________________________ 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 : Tue Jul 03 2001 - 17:43:24 PDT