From: Carlos Sevillano (carlos_sevillano@ureach.com)
Date: Tue Sep 14 2004 - 10:33:23 EDT
Solaris 2.6/8/9
pkgadd for software deployment (operator non-root accounts)
SCsu NIS+ (some environments)
Keon PPAK (other environments)
SCsu CA Etrust (other environments)
We need a way to allow operators to install software using
pkgadd from their functional accounts. Our software is designed
and implemented via "pkgadd", DBA changes, new software,
application releases... just about anything in a variety of
environments with different security infrastructures deploy
software via "pkgadd".
The operators are in a captive menu and my goal is to provide a
universal way to have them install different software via
pkgadd. We have a procedure for authenticating access, release
of software, approval and change control. But I am stuck in
actually allowing their "operator" non-root account to run
pkgadd.
Because we use Keon, NIS+, CA Etrust... PPAK, su, and SCsu on
different platform and diffenrent environments... what works on
PPAK might not work on SCsu systems etc. The solution would
have been SCsu definitions to allow access to root or just pkg
as root or pbrun pkgadd for the operator. However, our internal
secrity groups do not want to support those configurations. I
am looking for a self contained Universal solution (C program,
Perl Script or end-to-end procedure) to allow operators to
deploy software vi pkgadd.
Does anyone have a working wrapper for allowing pkgadd to
non-root users? A working solution? Keep in mind htat our
packages cannot be modified (checksum and Audit rule). We need
something that can do what we now do manually. Run pkgadd
(answer some questions or prompts (via the operators) - though
we could try an unattended install... the format of the package
and the questions it asks changes from pacakage to package and
release to release).
We tried several SUID files and script even C programs... in all
cases pkgadd exited indicating that the user is not root.
There are some posting on the Net and SUMMARIES out there.. but
not end-to-end solution (something that can be model after or
copied for rapid implementation). This solution or suggesting
won't work for us.. because our packages are checksum and cannot
be modified by SA (Audit issue) we must take the package as is
and install it ei:
On Sun, Mar 31, 2002 at 08:54:47AM -0600, Mark McCullough wrote:
> ...
> My problem is dealing with "testers" who think that it is a
fine idea
> to give out pkgadd (Solaris) via sudo several times a week. I
don't
> have nearly the time to do the pkgadds for the user who might
pkgadd
> several times in an afternoon, study it for a few days, then
repeat.
This won't work in all circumstances. You might want to provide
a custom wrapper for pkgadd that is forced to use a specific
'admin' file, and a few custom restrictions:
Limits in wrapper itself:
- not allowed to pkgadd/pkgrm anything named SUNW*
Limits in 'admin' file:
- not allowed to pkgadd/pkgrm anything with privileged
install/cleanup
scripts
- not allowed to install anything that conflicts with another
package.
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:29:26 EDT