Re: [PATCH] enable /proc/$$/loginuid

On Tue, 2005-01-18 at 11:15, Serge Hallyn wrote: > I'm assuming the loginuid needs to be set at the first login, and be > immutable. Let's say we have an audit rule for some inode ino. A task > accessing that inode won't have an audit_context until it touches that > inode. So there's no loginuid to associate with that action at that > time. I don't believe that this is how the current audit code works. An audit context is initially set up for a task upon fork/clone via copy_process-> audit_alloc. audit_alloc calls audit_filter_task to see if the task has auditing completely disabled (which must be explicit; the default is to build a context in the absence of any filters to disable). Unless auditing is completely disabled for the task, audit_alloc creates an audit context for the task, preserves the loginuid from the parent (with my fix), and sets the syscall auditing flag. Subsequently, audit-related information (e.g. paths, inodes, devices) is captured during syscalls made by the task, and at syscall exit, audit_syscall_exit calls audit_get_context, which now checks filters to see if it should mark the context as auditable (and any earlier calls to audit_log during the syscall e.g. by SELinux will have already marked it auditable). If auditable, audit_syscall_exit will then call audit_log_exit to perform the actual logging. It has to work in this way for the reason you describe - we don't know whether the task will trigger any auditable events a priori, so we must set up an audit context and start capturing information unless the task is explicitly marked as not requiring any auditing at all.