Produce a human-readable report from /etc/sudoers
am 23.04.2008 17:18:25 von cdmonline
My /etc/sudoers file is expansive and complex and I need a way to
produce a more human readable form of its contents.
I'd like to be able to report on the following:
1) Given a user - which command(s) may be executed and on which
system(s)
2) Given a system - which command(s) may be executed by which user(s)
3) Given a command - which user(s) may executed the command on which
system(s)
All of this information is already in the /etc/sudoers file, of
course, but it is difficult to report on any of the above scenarios
without tediously trawling through the file.
I have 2 versions of the sudoers file. 1 contains netgroup information
with the + notation and the other is an expanded version where all the
netgroups (users and hosts) is already exapanded in comma-delimited
form.
I've tried shell-scripting this but can't quite get it to work exaclty
as I want it to.
- CDM
Re: Produce a human-readable report from /etc/sudoers
am 24.04.2008 01:44:43 von mop2
I think, grep is the solution.
As example:
grep 'user[, ]' /etc/sudoers|grep -v '^#'|cut -d' ' -f2-
If user, system and command are distinct "strings" (never match), it
is more easy.
Suggestion:
Select a complex line, post it and show expected filter outputs
(1,2,3).
cdmonl...@mac.com wrote:
> My /etc/sudoers file is expansive and complex and I need a way to
> produce a more human readable form of its contents.
>
> I'd like to be able to report on the following:
>
> 1) Given a user - which command(s) may be executed and on which
> system(s)
> 2) Given a system - which command(s) may be executed by which user(s)
> 3) Given a command - which user(s) may executed the command on which
> system(s)
>
> All of this information is already in the /etc/sudoers file, of
> course, but it is difficult to report on any of the above scenarios
> without tediously trawling through the file.
>
> I have 2 versions of the sudoers file. 1 contains netgroup information
> with the + notation and the other is an expanded version where all the
> netgroups (users and hosts) is already exapanded in comma-delimited
> form.
>
> I've tried shell-scripting this but can't quite get it to work exaclty
> as I want it to.
>
> - CDM
Re: Produce a human-readable report from /etc/sudoers
am 24.04.2008 09:55:59 von PK
On Wednesday 23 April 2008 17:18, cdmonline@mac.com wrote:
> My /etc/sudoers file is expansive and complex and I need a way to
> produce a more human readable form of its contents.
>
> I'd like to be able to report on the following:
>
> 1) Given a user - which command(s) may be executed and on which
> system(s)
> 2) Given a system - which command(s) may be executed by which user(s)
> 3) Given a command - which user(s) may executed the command on which
> system(s)
>
> All of this information is already in the /etc/sudoers file, of
> course, but it is difficult to report on any of the above scenarios
> without tediously trawling through the file.
>
> I have 2 versions of the sudoers file. 1 contains netgroup information
> with the + notation and the other is an expanded version where all the
> netgroups (users and hosts) is already exapanded in comma-delimited
> form.
>
> I've tried shell-scripting this but can't quite get it to work exaclty
> as I want it to.
There is a script (sudoers-lint) floating around in the Internet, which
claims to parse the sudoers file and produce some reports about number and
names of users, commands, hosts, etc. It probably doesn't do exactly what
you need, but it could be a starting point to modify. At least, it already
does the hard work of parsing the file.
Note that I haven't tried it...just googled a bit and read the description.
I'm no perl expert either so I don't know whether it would be easily
modified to suit your needs. However, hope the information helps somehow.
If anything else fails, you could always write your own parser (probably
using lex/yacc) based on the grammar provided in the sudoers man page.
--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.