The General consensus was to use sudo. In most cases it would do but it does not work with KEON security model. It uses the keon database instead of what you define on sudo. I am hoping someone with real programming skills will show me how to fix (program below) it so that it works as non-root. There are no blatant security issues the users in question are bound to captive menus and they get one-time SafterWord passwords released by Security for one-time install of a particular package. All work is done through Code Change Control and Business change control. My hope is that I can get a basic SUID program to work but several tries and approaches have failed and all the programs I code come back with the message that I am not root ei. #include <unistd.h> #include <stdio.h> #include <sys/types.h> #include <unistd.h> main() { uid_t uid, euid; gid_t gid, egid; /* get real user-id */ uid = getuid(); /* get effective user-id */ euid = geteuid(); /* get real group-id */ gid = getgid(); /* get effective group-id */ egid = getegid(); /* set effective user-id */ seteuid(0); setgid(0); system("/usr/sbin/pkgadd -d /a/PKG-LOCAL/ddd-3.3-sol8-sparc-local"); seteuid(getuid()); setgid(getegid()); } I want to switch from the users uid and effective uid to root and them set-it back to unprivilage and exit back to captive menu. The goal is to have a non root user apply a package. Carlos ---- forwarded message attached --- ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Date: Tue, 14 Sep 2004 14:33:23 GMT Message-Id: <41470133.20557@www20.ureach.com> Received: from [162.84.176.148] by www20.ureach.com via HTTP; Tue, 14 Sep 2004 14:33:23 GMT To: sunmanagers@sunmanagers.org From: Carlos Sevillano <carlos_sevillano@ureach.com> Reply-to: <carlos_sevillano@ureach.com> Subject: pkgadd for operators (non-root users) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-vsuite-type: e 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/sunmanagersReceived on Wed Nov 3 14:23:35 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:39 EST