[sudo-users] user+group and root+group privs? (was Re: Root sudo privileges)

[L. A. Walsh]

David Ledger wrote:
> Having root not able to change uid to the database owner with sudo would mean that root would be one user that couldn't operate on the database without an "opps - silly me. I must remember to add that rule to sudoers".
>   
---
It may be that my sudo is in need of updating -- but have been
a bit afraid to do so, since each new version seems to bring more
restrictions that cause problems that I have to work around (ex:
my local security policy has each user and daemon in their own group 
(usually with UID=GID unless some compat reason).  Many security tools
are forgetting about groups and disallow access, reset access or
disabled functionality if group-write permission is set (via permissions)
or access lists.  But here's a case in point (but all admit, may
be fixed in a later version) -- (?)

Using sudo version:

Sudo version 1.8.7
Sudoers policy plugin version 1.8.7
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.7

Suppose the database is owned by group "Media"... I tried this:
  > sudo -E -g Media ls
  Sorry, user lindaw is not allowed to execute '/usr/bin/ls' as
   lindaw:Media on Ishtar.
------
Normally, I would have expected sudo to execute /usr/bin/ls as
"root:Media".   But fine,
lets try it as 'root':
  > sudo (<cr>)
  # sudo -E -g Media ls
  Sorry, user root is not allowed to execute '/usr/bin/ls' as
   root:Media on Ishtar.
---

Regardless if root and lindaw aren't specifically listed in sudoers
to be able to run the "open-for-all-to-run", "ls", as Media,
both are in group Media (as a supplementary group):

  > grep Media /etc/group
  Media:!:260:Media,lindaw,root,minidlna,Bliss\lindaw

In sudoers, both root and lindaw can execute any command, set ENV, and
use no passwd:

  root ALL=(ALL) NOPASSWD: SETENV: ALL
  lindaw ALL=(ALL) NOPASSWD: SETENV: ALL

So why the denial (or is this fixed?)?  I.e. since they both can access 
things in group Media, why the needless extra work to either puzzle out 
a working config (for EACH special group and EACH special 
group-authorized "db" or "program") or figure out a way to get around 
another group-security-policy annoyance...er, "feature"... ;-)

 
thanks!
- linda