[sudo-users] Sudo for groups?
lists at dawes.za.net
Wed Apr 6 12:59:48 EDT 2005
Ladner, Eric (Eric.Ladner) wrote:
> I think you're in luck.
> According to the sudoers man page
> A User_List is made up of one or more usernames, system groups (prefixed
> with '%'), netgroups (prefixed with '+') and other aliases. Each list
> item may be prefixed with one or more '!' operators. An odd number of
> '!' operators negate the value of the item; an even number just cancel
> each other out.
> Eric Ladner, Systems Analyst
> RFMS IT Support
Thanks for your response.
But doesn't this simply control WHICH users are allowed to do things?
i.e. members of the specified group, rather than listing them individually?
I am trying to allow users to gain controlled access to a specific group
rather than to a specific user, which is what sudo normally does.
I think that I am looking for group support in the Runas_Alias /
Runas_List / Runas_Spec keywords.
> -----Original Message-----
> From: sudo-users-bounces at courtesan.com
> [mailto:sudo-users-bounces at courtesan.com] On Behalf Of
> lists at dawes.za.net
> Sent: Wednesday, April 06, 2005 5:19 AM
> To: sudo-users at courtesan.com
> Subject: [sudo-users] Sudo for groups?
> Hi folks,
> I have a situation that I am trying to correct as best I can.
> A company has a legacy application that needs world-writable permissions
> on its data files to operate. I think this is bad practice, and am
> trying to limit this to group writable for a specific application group.
> There are then a couple of possibilities:
> 1) Add all application users to the application group
> 2) Use a setuid/setgid wrapper that calls the application.
> 1) has the disadvantage that the user is then still able to modify the
> data files directly.
> 2) seems to me to be a workable solution.
> Trying not to reinvent the wheel (and fall into the same security traps
> that everyone else has already climbed out of), I thought that maybe
> sudo could let me do this.
> One thing that I would like to have, though, is that the userid should
> not be changed, just the group. This is because the application checks
> the uid when deciding what operations the user should be allowed to
> Were it not for the "own userid" condition, I could just create an
> user who is a member of the "appgrp" group, and allow members of the
> group to execute /opt/app/bin/app as "appuser".
> SetGID directories could even control the permissions and ownership of
> spool files . . .
> Is such a thing possible with sudo? I have checked the archives, and saw
> a post last year referring to an application called "hat" that set
> hardcoded groups.
> Unfortunately, it seems to be a private app, and there was no further
> discussion on the list.
> Ideally, what I would like is something like:
> %appusers ALL = (%appgrp) NOPASSWD: /opt/app/bin/app
> Where member of the appusers group would be permitted to run
> /opt/app/bin/app with the primary group set to be appgrp, but their UID
> still their own.
> Any suggestions? Am I out of luck?
> I should mention that the platform is Tru64 Unix V40.F and V5.1B, so the
> Linuxish alternative of allowing the users to execute /usr/bin/sg appgrp
> /opt/app/bin/app is not available. Thinking about it, though, I don't
> think that would work anyway, due to the uid issue :-(
> Many thanks for any assistance.
> sudo-users mailing list <sudo-users at sudo.ws> For list information,
> options, or to unsubscribe, visit:
*ALL* messages to discard at dawes.za.net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"
More information about the sudo-users