On Sat, 8 May 2010 00:37:22 -0400 "Stephen Repetski" <[email protected]> wrote:
> Could you explain a bit more about the audit logs showing the ACL > change data (and perhaps some example usage)? Our institution has had > some of the same concerns brought up in this thread, and hope to > implement one or a series of solutions to prevent damage from poorly > thought out ACLs that users may create. While this would be an > after-the-fact log scan, it would still prove to be extremely useful. Example log entry: Sat May 8 00:41:04 2010 [7] EVENT AFS_SRX_FchACL CODE 0 NAME adea...@localcell HOST 192.168.85.100 ID 1 FID 536870942:1:1 ACL 3 0 system:administrators 127 system:anyuser 8 adeason 13 That's the result of me doing 'fs sa . adeason rli' Most of what you care about is the FID and the actual ACL contents, but some explanation for other fields: AFS_SRX_StACL just indicates it's a StoreACL operation. Code 0 means success. NAME is who's doing the operation, ID is their viceid. (Those are --UnAuth-- and 32766, respectively, for unauthenticated accesses) HOST is the client host, FID is the FID, ACL is the ACL. The ACL format is the same as the raw format passed between the kernel and 'fs' iirc. After the string 'ACL' you see stuff in this format: <number of positive ACL entries, call it N> <number of negative ACL entries, call it M> <positive ACL entry 1> ... <positive ACL entry N> <negative ACL entry 1> ... <negative ACL entry N> And individual ACL entry consists of the user/group it applies to, followed by a space, followed by the rights mask in decimal. Here's what ACL rights correspond to what values in the rights mask: r 0x00000001 w 0x00000002 i 0x00000004 l 0x00000008 d 0x00000010 k 0x00000020 a 0x00000040 A 0x01000000 B 0x02000000 C 0x04000000 D 0x08000000 E 0x10000000 F 0x20000000 G 0x40000000 H 0x80000000 Although at least currently it looks like if H is set, the mask appears negative in the audit log output, presumably since something is treating the mask as signed 32 bits. So, read in the value as a 32-bit signed integer and do the rights mask calculation with that if you don't want H screwing up your rights calculation. Another example, with a negative entry. I do 'fs sa . adeason w -neg' and I get: Sat May 8 00:41:04 2010 [8] EVENT AFS_SRX_StACL CODE 0 NAME adea...@localcell HOST 192.168.85.100 ID 1 FID 536870942:1:1 ACL 3 1 system:administrators 127 system:anyuser 8 adeason 13 adeason 2 When analyzing these, it can still take some time to figure out what file the FID corresponds to. But the FID is all you need if you want some program to directly make a StoreACL call in response to this. Note that audit logging is synchronous, so it can slow down fileserver operations if you're heavily loaded enough. There is also no 'good' way to rotate the audit logs. If you log to a file, there is currently no mechanism for the fileserver to reopen the log file (aside from restarting it), so you usually have to truncate it and hope for the best. You can also log to a fifo and have something read from it, but if for whatever reason that program takes a long time to read from the pipe, iirc the fileserver will wait for it before resuming. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
