Sorry for slow response. Matthew Wilcox wrote: > When the rule is put in place, say "No modifications to /etc/passwd", > look up the inode and major:minor of /etc/passwd. If there's a rename, > look up the new inode number. If it's mounted elsewhere, it doesn't > matter, they still can't modify it because it has the same > major:minor:inode. If write access is denied because of a rule "No modifications to /etc/passwd", a rule "Allow modifications to /tmp/passwd" can no longer be enforced after "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done. "No modifications" (i.e. "forbid modifications") and "Allow modifications" (i.e. "don't forbid modifications") are incompatible rules as long as the rules are described using pathnames but the judgment is done using inodes (or labels). If rules are described like "No modifications to passwd_t", it is correct to deny modifications of the file when the file with passwd_t was renamed or bind-mounted or hard-linked. Those who want to do access restriction based on the entity of the file prefer rules described using inodes (or labels). If rules are described like "No modifications to /etc/passwd" and "Allow modifications to /tmp/passwd", it is wrong to deny modifications of the file when /etc/passwd was renamed or bind-mounted or hard-linked to /tmp/passwd . Those who want to do access restriction based on the location of the file prefer rules described using pathnames. SELinux and Smack are the former. AppArmor and TOMOYO Linux are the latter. > Is this workable? I'm afraid it is unlikely. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
