Eric Paris wrote: > This new acc_mode flag is just to tell the security system this > inode permission check is from the access system call. The security > system can use this information as it finds appropriete. In > particular SELinux plans to use this flag to alter what we choose to > audit and what we do not choose to audit. Does "as it finds appropriate" mean robust applications should try an operation anyway even if access() says no from now on? Btw, since you're looking at access(), the kernel could do with euidaccess() or a flag ACCESS_EUID. (Either would be trivial to implement). Glibc provides eaccess/euidaccess functions, but they work by calling stat() and checking the mode bits when euid != ruid || egid != rgid, which is clearly not very nice with ACLs, and perhaps not ideal for SELinux's auditing of access calls either. -- Jamie -- 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
