[OpenAFS] Re: Monitoring bad ACLs of webpages: best practices? faster
search?
Andrew Deason
adeason@sinenomine.net
Sat, 8 May 2010 01:00:45 -0500
On Sat, 8 May 2010 00:37:22 -0400
"Stephen Repetski" <skrepetski@gmail.com> 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 adeason@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 adeason@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
adeason@sinenomine.net