From AGHORBAN at amfam.com Fri Jul 1 11:23:06 2005 From: AGHORBAN at amfam.com (Ghorbani, Anoosh N) Date: Fri, 1 Jul 2005 10:23:06 -0500 Subject: [sudo-users] Sudo on AIX 5.3 Message-ID: Hello all, Has anyone tested sudo on AIX 5.3. So far I have seen AIX 5.1 being reported. Thank you Anoosh Ghorbani From zvika at aeserv.technion.ac.il Mon Jul 4 06:23:45 2005 From: zvika at aeserv.technion.ac.il (Zvi Bar-Deroma) Date: Mon, 4 Jul 2005 13:23:45 +0300 (IDT) Subject: [sudo-users] Sudo on AIX 5.3 In-Reply-To: References: Message-ID: On Fri, 1 Jul 2005, Ghorbani, Anoosh N wrote: > > Hello all, > > > Has anyone tested sudo on AIX 5.3.So far I have seen AIX 5.1 being > reported. Donno about 5.3, but it works fine here on 5.2. Regards, /Zvika > > Thank you > Anoosh Ghorbani > > ____________________________________________________________ > sudo-users mailing list > For list information, options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users From Name Withdrawn Mon Jul 4 21:23:53 2005 From: Name Withdrawn (Name Withdrawn) Date: Mon, 04 Jul 2005 21:23:53 -0400 Subject: [sudo-users] RE: sudo-users Digest, Vol 31, Issue 2 In-Reply-To: <200507041800.j64I04H6009795@xxx.courtesan.com> Message-ID: I am using it on AIX 5.3. I use mainly sudosh with it; new to sudo; and it works fine. Regards, Manish

Thanks and regards,

Manish B. Dhokiya




----Original Message Follows----
From: sudo-users-request at courtesan.com
Reply-To: sudo-users at courtesan.com
To: sudo-users at sudo.ws
Subject: sudo-users Digest, Vol 31, Issue 2
Date: Mon, 4 Jul 2005 12:00:04 -0600 (MDT)

Send sudo-users mailing list submissions to
sudo-users at sudo.ws

To subscribe or unsubscribe via the World Wide Web, visit
http://www.sudo.ws/mailman/listinfo/sudo-users
or, via email, send a message with subject or body 'help' to
sudo-users-request at sudo.ws

You can reach the person managing the list at
sudo-users-owner at sudo.ws

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sudo-users digest..."


Today's Topics:

1. Re: Sudo on AIX 5.3 (Zvi Bar-Deroma)


----------------------------------------------------------------------

Message: 1
Date: Mon, 4 Jul 2005 13:23:45 +0300 (IDT)
From: Zvi Bar-Deroma <zvika at aeserv.technion.ac.il>
Subject: Re: [sudo-users] Sudo on AIX 5.3
To: "Ghorbani, Anoosh N" <AGHORBAN at amfam.com>
Cc: sudo-users at sudo.ws
Message-ID:
<Pine.A41.4.61_heb2.09a.0507041322550.479318 at aeserv.technion.ac.il>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 1 Jul 2005, Ghorbani, Anoosh N wrote:

>
> Hello all,
>
>
> Has anyone tested sudo on AIX 5.3.So far I have seen AIX 5.1 being
> reported.

Donno about 5.3, but it works fine here on 5.2.

Regards,
/Zvika

>
> Thank you
> Anoosh Ghorbani
>
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users


------------------------------

____________________________________________________________
sudo-users mailing list <sudo-users at sudo.ws>
For list information, options, or to unsubscribe, visit:
http://www.sudo.ws/mailman/listinfo/sudo-users

End of sudo-users Digest, Vol 31, Issue 2
*****************************************
From aaron777 at gmail.com Sun Jul 10 15:09:44 2005 From: aaron777 at gmail.com (Aaron Spangler) Date: Sun, 10 Jul 2005 15:09:44 -0400 Subject: [sudo-users] sudo-1.6.8p7 + ldaps + self signed vertificate In-Reply-To: <32827.62.194.92.14.1111733099.squirrel@wmail.websystems.nl> References: <32827.62.194.92.14.1111733099.squirrel@wmail.websystems.nl> Message-ID: <1db2507705071012091d0dfda3@mail.gmail.com> I got to thinking about this one. I think for whatever reason, the LDAP libraries are requiring a certificate that it trusts. If you specify the "tls_cacertfile" that contains the certificate of the ldap server it should solve the problem. P.S. Sorry for taking so long to respond to this. -Aaron On 3/25/05, Justin Albstmeijer wrote: > sudo was build against openldap on the client I'm testing on. > > Please let me know if you need additional information. > > Justin > > > Did you build sudo against OpenLDAP or another LDAP SDK? If you built > it against OpenLDAP, it sounds like we will need to add some > > configuration parameters that allow you to specify where your trusted > certificate signers are. > > > > -Aaron > > > > > > On Thu, 24 Mar 2005 17:21:35 +0100 (CET), Justin Albstmeijer > > wrote: > >> > >> sudo (--with ldap) works fine as long as I don't use SSL for LDAP. > >> > >> I get the same error as with ldapsearch when not setting "TLS_REQCERT > allow" in /etc/openldap/ldap.conf. Ldapsearch works fine now, but sudo > still is not working with this option set. > >> > >> Any idea? > >> > >> ------- > >> TLS certificate verification: Error, self signed certificate > >> TLS trace: SSL3 alert write:fatal:unknown CA > >> TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS > trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't > connect. > >> ------- > >> > >> ____________________________________________________________ > >> sudo-users mailing list > >> For list information, options, or to unsubscribe, visit: > >> http://www.sudo.ws/mailman/listinfo/sudo-users > >> > > > > > > > > > From aaron777 at gmail.com Sun Jul 10 15:25:05 2005 From: aaron777 at gmail.com (Aaron Spangler) Date: Sun, 10 Jul 2005 15:25:05 -0400 Subject: [sudo-users] Re: sudo+ldap+redhat (fedora) In-Reply-To: References: Message-ID: <1db25077050710122536eb265b@mail.gmail.com> Thanks for the debugging information. Sorry I took so long to respond. For whatever reason, it appears that linux is unable to determine the proper netgroups. Sudo simply uses the netgr_matches() libc call that is common on all Unix operating systems. I suspect that since Linux itself is not able to read the netgroups there might be some other issue not related to sudo. Here are some things to try: 1) I am assuming that your netgroup information is stored in LDAP. Verify that the 'netgroups' line in /etc/nsswitch.conf reads: netgroups: ldap 2) Verify that nss_ldap is looking for the netgroups in the correct place. Check your /etc/ldap.conf and look for the line. It should point to the container in your LDAP server where the netgroup information lives. nss_base_netgroup ou=Netgroup,dc=example,dc=com?one Hopefully that should get you going. On 5/11/05, jan.david at agfa.com wrote: > > Hello Aaron, > > I have been working with the SunOne directory server, Solaris and Sudo for > a while now and it all works fine. Unfortunately, my boss decided that we > needed to have some Linux servers and now things do not work so well > anymore. > > Maybe you can help me? > > Here's the problem. > > On Solaris, we have a netgroup called "ucc". In the /etc/nsswitch.conf file > you'll find: > > passwd: compat and in /etc/passwd you'll find: > > + at ucc > > Different users belong to this netgroup, such as me (account: eyorm). > > If I perform a "sudo -l" on Solaris, it correctly looks up the netgroup, > "ucc" and finds that since I belong to it, I can perform certain > priviledged tasks. > On Linux (Redhat Fedora) this does not quite seem to work. The netgroups > are being looked up, but the users that belong to that group are not. > > Note that sudo works if I put my account directly into the sudoRole or if I > use a posixgroup (e.g. %wheel). It does not work with netgroups however. My > guess is that this might have something to do with the padl libraries?? > > Here's the output of "sudo -l": > > > $ sudo -l > LDAP Config Summary > =================== > host ldap1 ldap2 > port 389 > ldap_version 3 > sudoers_base ou=sudoers,dc=com,dc=agfa > binddn (anonymous) > bindpw (anonymous) > ssl no > =================== > ldap_init(ldap1 ldap2,389) > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03) > ldap_bind() ok > found:cn=defaults,ou=sudoers,dc=be,dc=local > ldap sudoOption: 'logfile=/var/log/sudo.log' > ldap sudoOption: 'lecture=never' > ldap sudoOption: 'ignore_local_sudoers' > ldap search > '(|(sudoUser=eyorm)(sudoUser=%wheel)(sudoUser=%wheel)(sudoUser=%vrtsadm)(sudoUser=%f_cc_mq)(sudoUser=%wsa_user)(sudoUser=ALL))' > ldap search 'sudoUser=+*' > found:cn=legato,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+operations' ... not > found:cn=saprouter,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+sap' ... not > found:cn=nagiosadmin,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+nagios' ... not > found:cn=smsadmin,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+nagios' ... not > ldap sudoUser netgroup 'nagios' ... not > found:cn=jcommerce,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+jcommerce' ... not > found:cn=vcs,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+orausers' ... not > ldap sudoUser netgroup 'lp0adm' ... not > ldap sudoUser netgroup 'lp4adm' ... not > found:cn=unixadmin,ou=sudoers,dc=be,dc=local # This is the sudorole > that should match. It finds the "ucc" netgroup to which I belong, but > doesn't check the netgroup entries ... > ldap sudoUser netgroup '+ucc' ... not > ldap sudoUser netgroup '+dba' ... not > ldap sudoUser netgroup 'unixcc' ... not > ldap sudoUser netgroup 'support' ... not > found:cn=mfskbt,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+mfs' ... not > found:cn=mfskbd,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+mfs' ... not > found:cn=sapportal,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+sap' ... not > found:cn=eccadmin,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+webusers' ... not > found:cn=autonomy,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup 'autonomy' ... not > ldap sudoUser netgroup 'amctd' ... not > ldap sudoUser netgroup 'amady' ... not > ldap sudoUser netgroup 'agpvd' ... not > ldap sudoUser netgroup 'amgxz' ... not > ldap sudoUser netgroup '+operations' ... not > found:cn=rdmpasswd,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+operations' ... not > found:cn=ioscadmin,ou=sudoers,dc=be,dc=local > ldap sudoUser netgroup '+iosc' ... not > user_matches=0 > host_matches=0 > sudo_ldap_check(50)=0x44 > eyorm is not in the sudoers file. This incident will be reported. > > > Any help would be appriciated. > > Best Regards, > > Jan > > From aaron777 at gmail.com Sun Jul 10 15:53:52 2005 From: aaron777 at gmail.com (Aaron Spangler) Date: Sun, 10 Jul 2005 15:53:52 -0400 Subject: [sudo-users] Re: Sudo 1.6.8p8 - on solaris 9 - with ldap In-Reply-To: <5C58EF56AE368A4696C1ABDF00A4E2E27A0A85@ukwam201.emea.corp.eds.com> References: <5C58EF56AE368A4696C1ABDF00A4E2E27A0A85@ukwam201.emea.corp.eds.com> Message-ID: <1db2507705071012537fd4cf27@mail.gmail.com> Paul, I suspect the problem you are running into is that the Sun One Libraries (assuming you compiled sudo against the Sun One Libraries rather than the built in Solaris libraries) require that the certificate and keyfile databases be specified. I do not believe at this time these features have been implemented into Sudo. I recommend you build sudo against OpenLDAP's SDK when compiling sudo and it will give you full start_tls and SSL capabilities. You can use OpenLDAP's SDK to talk with any LDAP server. - Aaron On 5/20/05, Macleod, Paul wrote: > > Good Afternoon Aaron, > > I've been able to build Sudo with gcc and get it to work a treat, with Sun > One Directory Server 5.2. > > However, that is over clear sockets on port 389. > > I'm struggling to get pick up TLS features, and wonder if there are any > pointers you may have to confirm that things are right. > > Pam authentications to the directory do work with TLS, have appropriate > certificates in place and such. ( e.g. /var/ldap/cert7.db and > /var/ldap/key3.db ). i.e. user authentication, hostname resolution etc. > > Is there any way to confirm that Sudo is actually trying to use > certificates? and that the build has picked up the appropriate configuration > options, and trying to use values defined in the ldap.conf file? > > Other than Sudo, there is no open source components installed. > > Thanks in advance for any help you can offer in resolving this. > > -Paul. > > > From aaron777 at gmail.com Mon Jul 11 14:51:50 2005 From: aaron777 at gmail.com (Aaron Spangler) Date: Mon, 11 Jul 2005 14:51:50 -0400 Subject: [sudo-users] Re: Sudo 1.6.8p8 - on solaris 9 - with ldap In-Reply-To: <5C58EF56AE368A4696C1ABDF00A4E2E2A73238@ukwam201.emea.corp.eds.com> References: <5C58EF56AE368A4696C1ABDF00A4E2E2A73238@ukwam201.emea.corp.eds.com> Message-ID: <1db250770507111151442499a7@mail.gmail.com> On 7/11/05, Macleod, Paul wrote: > Long story cut short at this point, I changed a > handful of lines of code within the sudo "ldap.c" module to use the > Mozilla api and it worked perfectly. Purely the establishing of a > connection over secure sockets - nothing else. > > Is there any plan to adopt support of the Mozilla libraries with Sudo, > or is it to remain open ldap / ssl? I would be interested in a diff in the code you changed.. -Aaron From wes.armour at diamond.ac.uk Tue Jul 19 06:17:53 2005 From: wes.armour at diamond.ac.uk (Wes Armour) Date: Tue, 19 Jul 2005 11:17:53 +0100 Subject: [sudo-users] Can I distribute the sudoers file as an rpm???? Message-ID: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> Hi all, I would like to distribute our sudoers file using an rpm package. My spec file looks like: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary: ...(lots of stuff...) %description The sudoers file gives limited root access to pcs %prep echo %setup echo %build echo %install %clean rm -rf $RPM_BUILD_ROOT %files %config /etc/sudoers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When I try to install the rpm I get: file /etc/sudoers from install of diamond-sudoers-0.1-1 conflicts with file from package sudo-1.6.7p5-30.1.1 Can I put something in my spec file to force the overwrite of the /etc/sudoers file??? Thanks in advance, Wes. From fabrice.schuler at ferma.fr Tue Jul 19 12:05:18 2005 From: fabrice.schuler at ferma.fr (Fabrice Schuler) Date: Tue, 19 Jul 2005 18:05:18 +0200 Subject: [sudo-users] troubleshooting with logs Message-ID: <42DD24BE.9020902@ferma.fr> Hello, I am currently running sudo 1.6.8p5 on solaris 5.7, and I have troubleshootings analyzing the logs. My problem is on the field TTY : For most of users, it corresponds to their TTY, which is what I want - it's OK then. But I have problems wih a daemon calling sudo. This daemon has no tty. On the first times (I would say for a couple of weeks), the TTY logged in sudo logs was "console" My problem is that this tty is reserved for the console, and, according to all the documentation I could find on the web, it is not possible to attach a process to this tty if not logged on the console (which is not the case - I am certain of that)... I agree this may not come from sudo, but if somebody ever had the same problem, or may know where it comes from or what I did for this to happen, I prefer to ask. For the moment, the tty logged is "unknown". Is it correct for a daemon to be logged with this TTY (I guess so, but as I said, I could not find any documentation about this) ? Sample from the logfile : Jul 19 16:48:12 2005 : user1 : HOST=machine : TTY=unknown ; PWD=/var/opt/directory/cores/ftc ; USER=user2 ; COMMAND=/bin/ksh -c . /export/home/user2/.profile >/dev/null 2>&1 ; export/home/user2/tata.ksh >/dev/null 2>&1 ; /opt/directory/sbin/ftcreport 1795193362 3 751458 tata $? >/dev/null 2>&1 >/dev/null 2>&1 Last question : could anybody tell me exactly when the TTY field will be set to "unknown" in the logs ? Thanks in advance, hopping my questions were clear enough to obtain an answer. Fabrice From Todd.Miller at courtesan.com Tue Jul 19 14:50:01 2005 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 19 Jul 2005 12:50:01 -0600 Subject: [sudo-users] troubleshooting with logs In-Reply-To: Your message of "Tue, 19 Jul 2005 18:05:18 +0200." <42DD24BE.9020902@ferma.fr> References: <42DD24BE.9020902@ferma.fr> Message-ID: <200507191850.j6JIo15B007316@xerxes.courtesan.com> In message <42DD24BE.9020902 at ferma.fr> so spake Fabrice Schuler (fabrice.schuler): > But I have problems wih a daemon calling sudo. This daemon has no tty. Are you sure about that? Unless the daemon disassociates from its tty it will still have one. This is usually accomplished via the setsid() system call. You should be able to tell via the ps command whether a process has a tty associated with it. > On the first times (I would say for a couple of weeks), the TTY logged > in sudo logs was "console" > My problem is that this tty is reserved for the console, and, according > to all the documentation I could find on the web, it is not possible to > attach a process to this tty if not logged on the console (which is not > the case - I am certain of that)... > I agree this may not come from sudo, but if somebody ever had the same > problem, or may know where it comes from or what I did for this to > happen, I prefer to ask. Not necesarily, the daemon in question might have been started by someone who was logged in on the console. Just because there is a process associated with a particular tty does not prevent a new user from logging in on that tty. > For the moment, the tty logged is "unknown". Is it correct for a daemon > to be logged with this TTY (I guess so, but as I said, I could not find > any documentation about this) ? Sudo logs the console as "unknown" when the ttyname() function returns NULL. This usually means there is no tty associated with the process. - todd From russell+sudo-users at loosenut.com Tue Jul 19 15:42:02 2005 From: russell+sudo-users at loosenut.com (Russell Van Tassell) Date: Tue, 19 Jul 2005 12:42:02 -0700 Subject: [sudo-users] Can I distribute the sudoers file as an rpm???? In-Reply-To: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> References: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> Message-ID: <20050719194202.GD12137@loosenut.com> On Tue, Jul 19, 2005 at 11:17:53AM +0100, Wes Armour wrote: > Hi all, > > I would like to distribute our sudoers file using an rpm package. > > [...] > > When I try to install the rpm I get: > > file /etc/sudoers from install of diamond-sudoers-0.1-1 conflicts with > file from package sudo-1.6.7p5-30.1.1 Sounds like it's conflicting with the distribution's instance of the file... myself, I distribute the sudoers file in the distribution as a sudoers.dist file, copy it over if it doesn't already exist, then use a distribution mechanism such as scp or something more automated such as cfengine or the like to keep the distributed sudoers file up-to-date. Hope that somehow helps as an alternative... Russell -- Russell M. Van Tassell russell at loosenut.com Sign at state park: To determine the temperature of the water add 25 to the average height (in inches) of the swimmers presently in the water. This will give you the water temperature in degrees Fahrenheit. From donald.ritchey at exeloncorp.com Tue Jul 19 17:00:08 2005 From: donald.ritchey at exeloncorp.com (donald.ritchey at exeloncorp.com) Date: Tue, 19 Jul 2005 16:00:08 -0500 Subject: [sudo-users] troubleshooting with logs Message-ID: <886FDDC53963EB42AB925FC8F2AE1151080B375D@ccc2kxch01.ceco.com> Depending on the version of UNIX and the characteristics of the startup process used, daemon processes may have the console as their controlling TTY or they may have null entry, if the O/S updates the TTY information after the daemon disassociates itself from the TTY where it was started. Most daemons started while the system is booted will have the console as their controlling TTY during the startup process. That is because the console terminal is the default output destination of the run control programs that boot the system. As the run control program exits, it closes the console, which closes the daemon's terminal as well. Once the boot scripts or programs complete, the daemon process will then have a null TTY, since it has been effectively disassociated from that terminal. On occasion and, again, depending on the version of UNIX, the daemon may retain a connection to the console and this connection will show up associating the daemon with the console port. It is not a big deal most of the time, since the daemon processes are designed to run without a terminal connection to their standard-in, -out, and -error files. The most likely cause of a sudo entry with no controlling TTY is for a sudo command run from within a crontab entry or via an at(1) task. In this case, the crond daemon, which starts the process, normally has no controlling TTY and the cron process or at job inherits this lack of a controlling terminal. Additionally, if the daemon process is running as the root (or superuser ID), it may have the ability to open the console terminal for output, if that terminal is 'open'. (For example, the daemon may need to display status or error messages on the console. If the console is connected to a terminal or printer device, and the device is turned on, the daemon can send its messages or errors to the device.) Best wishes, Donald L. (Don) Ritchey Information Technology Exelon Corporation -----Original Message----- From: sudo-users-bounces at courtesan.com [mailto:sudo-users-bounces at courtesan.com]On Behalf Of Todd C. Miller Sent: Tuesday, July 19, 2005 1:50 PM To: Fabrice Schuler Cc: sudo-users at sudo.ws Subject: Re: [sudo-users] troubleshooting with logs In message <42DD24BE.9020902 at ferma.fr> so spake Fabrice Schuler (fabrice.schuler): > But I have problems wih a daemon calling sudo. This daemon has no tty. Are you sure about that? Unless the daemon disassociates from its tty it will still have one. This is usually accomplished via the setsid() system call. You should be able to tell via the ps command whether a process has a tty associated with it. > On the first times (I would say for a couple of weeks), the TTY logged > in sudo logs was "console" > My problem is that this tty is reserved for the console, and, according > to all the documentation I could find on the web, it is not possible to > attach a process to this tty if not logged on the console (which is not > the case - I am certain of that)... > I agree this may not come from sudo, but if somebody ever had the same > problem, or may know where it comes from or what I did for this to > happen, I prefer to ask. Not necesarily, the daemon in question might have been started by someone who was logged in on the console. Just because there is a process associated with a particular tty does not prevent a new user from logging in on that tty. > For the moment, the tty logged is "unknown". Is it correct for a daemon > to be logged with this TTY (I guess so, but as I said, I could not find > any documentation about this) ? Sudo logs the console as "unknown" when the ttyname() function returns NULL. This usually means there is no tty associated with the process. - todd ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users ************************************************************************ This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You. ************************************************************************ From bob at proulx.com Wed Jul 20 01:07:26 2005 From: bob at proulx.com (Bob Proulx) Date: Tue, 19 Jul 2005 23:07:26 -0600 Subject: [sudo-users] Can I distribute the sudoers file as an rpm???? In-Reply-To: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> References: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> Message-ID: <20050720050726.GC18741@dementia.proulx.com> Wes Armour wrote: > I would like to distribute our sudoers file using an rpm package. > When I try to install the rpm I get: > > file /etc/sudoers from install of diamond-sudoers-0.1-1 conflicts with > file from package sudo-1.6.7p5-30.1.1 I believe Russell Van Tassell's response identified your problem. > My spec file looks like: But I had to comment upon your spec file. > Summary: ...(lots of stuff...) Did you have a BuildRoot specified? > %description > The sudoers file gives limited root access to pcs > > %prep > echo > > %setup > echo > > %build > echo > > %install If those scripts are not used then don't include them in the spec file at all. Just remove them instead of creating noop scripts out of them. > %clean > rm -rf $RPM_BUILD_ROOT I think you have a critical error possible here. You omitted the header so we can't tell if you specified a BuildRoot. But from your %files section I gather not. In which case the rm -rf here could be a bad thing if $RPM_BUILD_ROOT were to default to /. Best to always specify a BuildRoot. > %files > %config /etc/sudoers This looks like you are packaging your live file. But you will be installing your package on your system and overwriting your live file too. So your source file is going to be overwritten in a moment with the new package file. I think that is a bad relationship. I would alway keep the source separate from the live copy. If you used a BuildRoot you could point into your source area. But then don't clean or it would remove your source. Personally I use rsync to keep the sudoers files in sync on the different machines. I have a cron task that pulls the sudoers files from a golden image server on a regular basis. Changes are made to the gold server. The new file is propagated to the clients by the crontask that runs rsync to get the new file. Therefore I recommend not packaging the configuration files but using a VCS to manage them. RPM packages are good for program files but not so good for managing configuration files. For configuration files I find an version control system to be much more practical. In addition to rsync other utilities such as radmin and cfengine are also well known alternatives for doing these types of tasks. Bob From fabrice.schuler at ferma.fr Wed Jul 20 03:37:18 2005 From: fabrice.schuler at ferma.fr (Fabrice Schuler) Date: Wed, 20 Jul 2005 09:37:18 +0200 Subject: [sudo-users] troubleshooting with logs In-Reply-To: <886FDDC53963EB42AB925FC8F2AE1151080B375D@ccc2kxch01.ceco.com> References: <886FDDC53963EB42AB925FC8F2AE1151080B375D@ccc2kxch01.ceco.com> Message-ID: <42DDFF2E.6050205@ferma.fr> donald.ritchey at exeloncorp.com wrote: > Depending on the version of UNIX and the characteristics of the startup > process used, daemon processes may have the console as their controlling > TTY or they may have null entry, if the O/S updates the TTY information > after the daemon disassociates itself from the TTY where it was started. My mistake : I forgot to precise that this process has not been launched from console. To be precise, it was launched from an xterm through a telnet connection, and not from the console (I am absolutely sure of this point). > Most daemons started while the system is booted will have the console > as their controlling TTY during the startup process. That is because > the console terminal is the default output destination of the run control > programs that boot the system. As the run control program exits, it closes > the console, which closes the daemon's terminal as well. Once the boot > scripts or programs complete, the daemon process will then have a null TTY, > since it has been effectively disassociated from that terminal. Well, indeed, it may be a little more complicated than what I explained first. Sorry for that, and for the lack of explanations. The fact is that I have a daemon (or something like : a process which father has been killed after a fork(), and the son is still alive) with no tty (sure of that). Every few seconds, this process executes scripts through the sudo command. It is the TTY field of those scripts that were shown on the tty "console", and are now sest to "unknown" (which is much better if I have well understood Todd's answers). > Additionally, if the daemon process is running as the root (or superuser > ID), > it may have the ability to open the console terminal for output, if that > terminal is 'open'. I take good notes, but I am sure the console is not "opened", and has nearly never been (except for a test I made, which did not change anything by the way). > Best wishes, > > Donald L. (Don) Ritchey > From: Todd C. Miller > > Sudo logs the console as "unknown" when the ttyname() function > returns NULL. This usually means there is no tty associated with > the process. Thank you for this information. > > - todd Thank you for all this information, which will be very usefull. Regards, Fabrice From wes.armour at diamond.ac.uk Wed Jul 20 05:35:25 2005 From: wes.armour at diamond.ac.uk (Wes Armour) Date: Wed, 20 Jul 2005 10:35:25 +0100 Subject: [sudo-users] Can I distribute the sudoers file as an rpm???? In-Reply-To: <20050720050726.GC18741@dementia.proulx.com> References: <1121768273.6436.13.camel@diamrl5001.diamond.ac.uk> <20050720050726.GC18741@dementia.proulx.com> Message-ID: <1121852125.3847.8.camel@diamrl5001.diamond.ac.uk> Thanks Russell & Bob your advice is appreciated. My full rpm spec is: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary: Sudoers file for linux %define version 0.1 Copyright: GPL Group: Applications Name: sudoers Provides: sudoers Release: 1 Source: sudoers-%{version}.tar.gz Version: %{version} #Buildroot: /tmp/sudoers-%{version} %description The sudoers file gives limited root access to pcs %prep echo %setup echo %build echo %install %clean rm -rf $RPM_BUILD_ROOT %files %config /etc/sudoers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The reason I would like to package the sudoers file as an rpm is because I have a red hat satellite server and so it would make things very easy if I could upload an rpm with the latest sudoers file in it and then all machines would update automatically. Thanks, Wes. On Tue, 2005-07-19 at 23:07 -0600, Bob Proulx wrote: > Wes Armour wrote: > > I would like to distribute our sudoers file using an rpm package. > > > When I try to install the rpm I get: > > > > file /etc/sudoers from install of diamond-sudoers-0.1-1 conflicts with > > file from package sudo-1.6.7p5-30.1.1 > > I believe Russell Van Tassell's response identified your problem. > > > My spec file looks like: > > But I had to comment upon your spec file. > > > Summary: ...(lots of stuff...) > > Did you have a BuildRoot specified? > > > %description > > The sudoers file gives limited root access to pcs > > > > %prep > > echo > > > > %setup > > echo > > > > %build > > echo > > > > %install > > If those scripts are not used then don't include them in the spec file > at all. Just remove them instead of creating noop scripts out of > them. > > > %clean > > rm -rf $RPM_BUILD_ROOT > > I think you have a critical error possible here. You omitted the > header so we can't tell if you specified a BuildRoot. But from your > %files section I gather not. In which case the rm -rf here could be a > bad thing if $RPM_BUILD_ROOT were to default to /. Best to always > specify a BuildRoot. > > > %files > > %config /etc/sudoers > > This looks like you are packaging your live file. But you will be > installing your package on your system and overwriting your live file > too. So your source file is going to be overwritten in a moment with > the new package file. I think that is a bad relationship. I would > alway keep the source separate from the live copy. If you used a > BuildRoot you could point into your source area. But then don't > clean or it would remove your source. > > Personally I use rsync to keep the sudoers files in sync on the > different machines. I have a cron task that pulls the sudoers files > from a golden image server on a regular basis. Changes are made to > the gold server. The new file is propagated to the clients by the > crontask that runs rsync to get the new file. Therefore I recommend > not packaging the configuration files but using a VCS to manage them. > > RPM packages are good for program files but not so good for > managing configuration files. For configuration files I find an > version control system to be much more practical. > > In addition to rsync other utilities such as radmin and cfengine are > also well known alternatives for doing these types of tasks. > > Bob From Eric.Ladner at chevron.com Thu Jul 21 11:43:37 2005 From: Eric.Ladner at chevron.com (Ladner, Eric (Eric.Ladner)) Date: Thu, 21 Jul 2005 10:43:37 -0500 Subject: [sudo-users] Can I distribute the sudoers file as an rpm???? Message-ID: <53D65D67C6AA694284F7584E25ADD354015E8183@nor935nte2k1.nor935.chevrontexaco.net> Get the original Sudo pakage (and spec), build it minus the config file and separate the config file into another RPM. IMO, however, this is off topic for the sudo-users mailing list and would be better at home in a Red Hat RPM builder or developers list. Eric Ladner, Systems Analyst RFMS IT Support -----Original Message----- From: sudo-users-bounces at courtesan.com [mailto:sudo-users-bounces at courtesan.com] On Behalf Of Wes Armour Sent: Wednesday, July 20, 2005 04:35 To: sudo-users at sudo.ws Subject: Re: [sudo-users] Can I distribute the sudoers file as an rpm???? Thanks Russell & Bob your advice is appreciated. My full rpm spec is: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary: Sudoers file for linux %define version 0.1 Copyright: GPL Group: Applications Name: sudoers Provides: sudoers Release: 1 Source: sudoers-%{version}.tar.gz Version: %{version} #Buildroot: /tmp/sudoers-%{version} %description The sudoers file gives limited root access to pcs %prep echo %setup echo %build echo %install %clean rm -rf $RPM_BUILD_ROOT %files %config /etc/sudoers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The reason I would like to package the sudoers file as an rpm is because I have a red hat satellite server and so it would make things very easy if I could upload an rpm with the latest sudoers file in it and then all machines would update automatically. Thanks, Wes. On Tue, 2005-07-19 at 23:07 -0600, Bob Proulx wrote: > Wes Armour wrote: > > I would like to distribute our sudoers file using an rpm package. > > > When I try to install the rpm I get: > > > > file /etc/sudoers from install of diamond-sudoers-0.1-1 conflicts > > with file from package sudo-1.6.7p5-30.1.1 > > I believe Russell Van Tassell's response identified your problem. > > > My spec file looks like: > > But I had to comment upon your spec file. > > > Summary: ...(lots of stuff...) > > Did you have a BuildRoot specified? > > > %description > > The sudoers file gives limited root access to pcs > > > > %prep > > echo > > > > %setup > > echo > > > > %build > > echo > > > > %install > > If those scripts are not used then don't include them in the spec file > at all. Just remove them instead of creating noop scripts out of > them. > > > %clean > > rm -rf $RPM_BUILD_ROOT > > I think you have a critical error possible here. You omitted the > header so we can't tell if you specified a BuildRoot. But from your > %files section I gather not. In which case the rm -rf here could be a > bad thing if $RPM_BUILD_ROOT were to default to /. Best to always > specify a BuildRoot. > > > %files > > %config /etc/sudoers > > This looks like you are packaging your live file. But you will be > installing your package on your system and overwriting your live file > too. So your source file is going to be overwritten in a moment with > the new package file. I think that is a bad relationship. I would > alway keep the source separate from the live copy. If you used a > BuildRoot you could point into your source area. But then don't clean > or it would remove your source. > > Personally I use rsync to keep the sudoers files in sync on the > different machines. I have a cron task that pulls the sudoers files > from a golden image server on a regular basis. Changes are made to > the gold server. The new file is propagated to the clients by the > crontask that runs rsync to get the new file. Therefore I recommend > not packaging the configuration files but using a VCS to manage them. > > RPM packages are good for program files but not so good for managing > configuration files. For configuration files I find an version > control system to be much more practical. > > In addition to rsync other utilities such as radmin and cfengine are > also well known alternatives for doing these types of tasks. > > Bob ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users From jstonecipher at inpac.com Tue Jul 26 10:23:13 2005 From: jstonecipher at inpac.com (John Stonecipher) Date: Tue, 26 Jul 2005 09:23:13 -0500 Subject: [sudo-users] Trouble installing SUDO 1.6.8p9 Message-ID: I'm trying to install 1.6.8p9 on an HP-UX 11 system. I'm not a UNIX sysadmin so I don't know what is supposed to happen during installation. I have followed the installation instructions and have found out I needed to run 'configure' with the --with-noexec option. After that I ran 'make'. I'll include the output from the below. After installation, I can't run sudo and I can't find a man page. What am I missing? ------------------------------------------------------------ /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (check.o) was detected. The linked output may not run on a PA 1.x system. /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (visudo.o) was detected. The linked output may not run on a PA 1.x system. S_GID=0 -DSUDOERS_MODE=0440 env.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 getspwuid.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 gettime.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 goodpath.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 fileops.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 find_path.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 interfaces.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 logging.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 parse.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 set_perms.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 sudo.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 sudo_edit.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 tgetpass.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 zero_bytes.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 ./auth/sudo_auth.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 ./auth/passwd.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 sudo.tab.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 lex.yy.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 alloc.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 defaults.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 err.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 fnmatch.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 strlcpy.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 strlcat.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 closefrom.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 snprintf.c cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 getprogname.c cc -o sudo check.o env.o getspwuid.o gettime.o goodpath.o fileops.o find_path.o interfaces.o logging.o parse.o set_perms.o sudo.o sudo_edit.o tgetpass.o zero_bytes.o sudo_auth.o passwd.o sudo.tab.o lex.yy.o alloc.o defaults.o err.o fnmatch.o strlcpy.o strlcat.o closefrom.o snprintf.o getprogname.o -lsec cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 visudo.c cc -o visudo visudo.o fileops.o gettime.o goodpath.o find_path.o sudo.tab.o lex.yy.o alloc.o defaults.o err.o fnmatch.o strlcpy.o strlcat.o closefrom.o snprintf.o getprogname.o ------------------------------------------------------------ Any and all help is appreciated. You can either email the list or email directly at my address listed below. Thanks, John ---- John Stonecipher Indiana Packers Corporation 765-564-7293 jstonecipher at inpac.com From punitha at visolve.com Tue Jul 26 23:45:26 2005 From: punitha at visolve.com (visolve.com) Date: Tue, 26 Jul 2005 20:45:26 -0700 Subject: [sudo-users] Re: sudo-users Digest, Vol 31, Issue 10 References: <200507261800.j6QI04Wn000791@xxx.courtesan.com> Message-ID: <002c01c5925d$a1a11730$2b0110ac@PunithaComputer> Hello John, Try the following Step 1 : Configure Options # export LDFLAGS="-Wl,+nodefaultrpath" # ./configure --prefix=/opt/iexpress/sudo --enable-log-host --with-kerb5 --with-pam --with-fqdn --with-sudoers-mode=644 \ --with-sudoers-uid=2 --with-sudoers-gid=2 --sysconfdir=/opt/iexpress/sudo/etc Step 2 : Compile the product Execute the following commands: # gmake # gmake install The product files will be installed under /opt/iexpress/sudo. Regards, Punitha, V. ----- Original Message ----- From: To: Sent: Tuesday, July 26, 2005 11:00 AM Subject: sudo-users Digest, Vol 31, Issue 10 > Send sudo-users mailing list submissions to > sudo-users at sudo.ws > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.sudo.ws/mailman/listinfo/sudo-users > or, via email, send a message with subject or body 'help' to > sudo-users-request at sudo.ws > > You can reach the person managing the list at > sudo-users-owner at sudo.ws > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sudo-users digest..." > > > Today's Topics: > > 1. Trouble installing SUDO 1.6.8p9 (John Stonecipher) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 Jul 2005 09:23:13 -0500 > From: "John Stonecipher" > Subject: [sudo-users] Trouble installing SUDO 1.6.8p9 > To: > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I'm trying to install 1.6.8p9 on an HP-UX 11 system. I'm not a UNIX > sysadmin so I don't know what is supposed to happen during installation. > I have followed the installation instructions and have found out I > needed to run 'configure' with the --with-noexec option. After that I > ran 'make'. I'll include the output from the below. After > installation, I can't run sudo and I can't find a man page. What am I > missing? > > > > ------------------------------------------------------------ > /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (check.o) was > detected. The linked output may not run on a PA 1.x system. > /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (visudo.o) > was detected. The linked output may not run on a PA 1.x system. > S_GID=0 -DSUDOERS_MODE=0440 env.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 getspwuid.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 gettime.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 goodpath.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 fileops.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 find_path.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 interfaces.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 logging.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 parse.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 set_perms.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 sudo.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 sudo_edit.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 tgetpass.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 zero_bytes.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 ./auth/sudo_auth.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 ./auth/passwd.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 sudo.tab.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 lex.yy.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 alloc.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 defaults.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 err.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 fnmatch.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 strlcpy.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 strlcat.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 closefrom.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 snprintf.c > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 getprogname.c > cc -o sudo check.o env.o getspwuid.o gettime.o goodpath.o > fileops.o find_path.o interfaces.o logging.o parse.o set_perms.o sudo.o > sudo_edit.o tgetpass.o zero_bytes.o sudo_auth.o passwd.o sudo.tab.o > lex.yy.o alloc.o defaults.o err.o fnmatch.o strlcpy.o strlcat.o > closefrom.o snprintf.o getprogname.o -lsec > cc -c -I. -I. -D_PATH_SUDOERS=\"/etc/sudoers\" > -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 > -DSUDOERS_MODE=0440 visudo.c > cc -o visudo visudo.o fileops.o gettime.o goodpath.o find_path.o > sudo.tab.o lex.yy.o alloc.o defaults.o err.o fnmatch.o strlcpy.o > strlcat.o closefrom.o snprintf.o getprogname.o > ------------------------------------------------------------ > > > Any and all help is appreciated. You can either email the list or email > directly at my address listed below. > > Thanks, > John > > ---- > John Stonecipher > Indiana Packers Corporation > 765-564-7293 > jstonecipher at inpac.com > > > > > ------------------------------ > > ____________________________________________________________ > sudo-users mailing list > For list information, options, or to unsubscribe, visit: > http://www.sudo.ws/mailman/listinfo/sudo-users > > End of sudo-users Digest, Vol 31, Issue 10 > ****************************************** > From mark at mbfk.net Thu Jul 28 08:08:24 2005 From: mark at mbfk.net (Mark Benschop) Date: Thu, 28 Jul 2005 14:08:24 +0200 (CEST) Subject: [sudo-users] set syslog_badpri in ldap ? Message-ID: <62790.145.78.21.5.1122552504.squirrel@www.mbfk.net> Hi All, I'm currently testing sudo 1.6.8p8 on HPUX 11i with the configuration in LDAP. Which all works very neatly !! I'm really very impressed by this. Stuffing the sudoconfig for quite a number of boxes will make my life very easy (for a change) :-) I set some of the default settings, like 'ignore_local_sudoers' and 'tty_tickets' in de cn=default. Now I want to change the syslog priority from alert to error. I see in the sudoers manpage it can be set in the /etc/sudoers file, which I am not using because of the 'sudoOption ignore_local_sudoers' Attribute i've set. But since the 'syslog_badpri' needs a value I can't just set it as a sudoOption in ldap, I suppose. So the question is : can syslog_badpri be set in LDAP, and if so ; How ?? Thanks for your help in this ! Regards, Mark From mousumi at india.hp.com Tue Jul 19 14:21:07 2005 From: mousumi at india.hp.com (Mousumi) Date: Tue, 19 Jul 2005 23:51:07 +0530 Subject: [sudo-users] Problem with CD command while using sudo Message-ID: <000001c593f2$475ad130$15c89610@admin5deb88403> Hi, I have installed sudo in one of the machines and configured various groups. In the visudo file, cd is listed as the command which can be used by all the groups. When executed cd under sudo, change directory does not happen. No error is reported, but the directory does not change. Any thoughts on how to resolve this issue? Thank you. regards, Mousumi email: mousumi at india.hp.com From russell+sudo-users at loosenut.com Fri Jul 29 02:50:25 2005 From: russell+sudo-users at loosenut.com (Russell Van Tassell) Date: Thu, 28 Jul 2005 23:50:25 -0700 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: <000001c593f2$475ad130$15c89610@admin5deb88403> References: <000001c593f2$475ad130$15c89610@admin5deb88403> Message-ID: <20050729065025.GB1210@loosenut.com> On Tue, Jul 19, 2005 at 11:51:07PM +0530, Mousumi wrote: > Hi, > > I have installed sudo in one of the machines and configured various groups. > In the visudo file, cd is listed as the command which > can be used by all the groups. When executed cd under sudo, change directory > does not happen. No error is reported, but the > directory does not change. Any thoughts on how to resolve this issue? In some shells, cd is an instrinsic, and in others it is a shell script which simply changes the cwd variable or some other PFM. Why, however, would you need to make cd a "sudo" command? Wouldn't "ls" or something else be a little more useful? (someone that cd's in to a directory that they aren't normally able to still won't be able to read it - so it's pretty useless, IMO) -- Russell M. Van Tassell russell at loosenut.com "There are no significant bugs in our released software that any significant number of users want fixed" - Bill Gates From mousumi at india.hp.com Fri Jul 29 09:35:47 2005 From: mousumi at india.hp.com (Mousumi Kadham) Date: Fri, 29 Jul 2005 19:05:47 +0530 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: <20050729065025.GB1210@loosenut.com> Message-ID: <200507291356.TAA24376@harbour.india.hp.com> Hi , Here is the situation. There are certain commands to be executed, files to be edited in a protected directory which has a long path. Without sudo and every one using root, administrators simply will do cd to the final directory and do many things like editing a few files etc. However with sudo, for every command, a long path has to be given and can quickly become very irksome to the administrators. Hence the question about 'cd' with sudo. Pls. help. Regards, Mousumi -----Original Message----- From: Russell Van Tassell [mailto:russell+sudo-users at loosenut.com] Sent: Friday, July 29, 2005 12:20 PM To: Mousumi Cc: sudo-users at sudo.ws Subject: Re: [sudo-users] Problem with CD command while using sudo On Tue, Jul 19, 2005 at 11:51:07PM +0530, Mousumi wrote: > Hi, > > I have installed sudo in one of the machines and configured various groups. > In the visudo file, cd is listed as the command which can be used by > all the groups. When executed cd under sudo, change directory does not > happen. No error is reported, but the directory does not change. Any > thoughts on how to resolve this issue? In some shells, cd is an instrinsic, and in others it is a shell script which simply changes the cwd variable or some other PFM. Why, however, would you need to make cd a "sudo" command? Wouldn't "ls" or something else be a little more useful? (someone that cd's in to a directory that they aren't normally able to still won't be able to read it - so it's pretty useless, IMO) -- Russell M. Van Tassell russell at loosenut.com "There are no significant bugs in our released software that any significant number of users want fixed" - Bill Gates From bob at proulx.com Fri Jul 29 12:20:19 2005 From: bob at proulx.com (Bob Proulx) Date: Fri, 29 Jul 2005 10:20:19 -0600 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: <200507291356.TAA24376@harbour.india.hp.com> References: <20050729065025.GB1210@loosenut.com> <200507291356.TAA24376@harbour.india.hp.com> Message-ID: <20050729162019.GB24646@dementia.proulx.com> Mousumi Kadham wrote: > Here is the situation. There are certain commands to be executed, files to > be edited in a protected directory which has a long path. Without sudo and > every one using root, administrators simply will do cd to the final > directory and do many things like editing a few files etc. However with > sudo, for every command, a long path has to be given and can quickly become > very irksome to the administrators. Hence the question about 'cd' with sudo. The problem is that 'cd' is a built-in to the command line shell. type -a cd cd is a shell builtin It is not possible to invoke it separately because on UNIX systems the current working directory is not something that is separate from the process. This is a fundamental difference between UNIX and MS systems. Therefore on UNIX systems it will never be effective to try to allow the 'cd' command to have privileges because the 'cd' command is not something that does anything by itself. Probably your best bet is to open the directory permissions up so that you don't need root to access the directory. Or alternatively if you do not want non-root users to be able to see into this directory you could set up a group to own the directory. Make it readable and searchable by that group and place the members of the team that need access in that group. Using group permissions is the traditional way of handling this. But it means that you would need to add all of your team members to that group. (Hint: If you are using HP-UX as I believe that you are then you will need /etc/logingroup to be a symlink to /etc/group.) Another possibility would be to create a script to do the common tasks. The script would embed all of those long and inconvenient paths and avoid the need for the users to type those in on the command line. Think of the way that 'vipw', 'visudo', and others of that like work. If you were editing a file you could create a script 'edit_myfile' or some such and allow it sudo access. Bob From Todd.Miller at courtesan.com Fri Jul 29 12:37:11 2005 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 29 Jul 2005 10:37:11 -0600 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: Your message of "Fri, 29 Jul 2005 19:05:47 +0530." <200507291356.TAA24376@harbour.india.hp.com> References: <200507291356.TAA24376@harbour.india.hp.com> Message-ID: <200507291637.j6TGbBa3010976@xerxes.courtesan.com> In message <200507291356.TAA24376 at harbour.india.hp.com> so spake "Mousumi Kadham" (mousumi): > Here is the situation. There are certain commands to be executed, files to > be edited in a protected directory which has a long path. Without sudo and > every one using root, administrators simply will do cd to the final > directory and do many things like editing a few files etc. However with > sudo, for every command, a long path has to be given and can quickly become > very irksome to the administrators. Hence the question about 'cd' with sudo. You can use group directory permissions to give the admins read and execute access to the directory in question. Then they can use sudo to do specific tasks. - todd From russell+sudo-users at loosenut.com Fri Jul 29 15:13:28 2005 From: russell+sudo-users at loosenut.com (Russell Van Tassell) Date: Fri, 29 Jul 2005 12:13:28 -0700 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: <20050729162019.GB24646@dementia.proulx.com> References: <20050729065025.GB1210@loosenut.com> <200507291356.TAA24376@harbour.india.hp.com> <20050729162019.GB24646@dementia.proulx.com> Message-ID: <20050729191328.GC1210@loosenut.com> On Fri, Jul 29, 2005 at 10:20:19AM -0600, Bob Proulx wrote: > Mousumi Kadham wrote: > > Here is the situation. There are certain commands to be executed, files to > > be edited in a protected directory which has a long path. Without sudo and > > every one using root, administrators simply will do cd to the final > > directory and do many things like editing a few files etc. However with > > sudo, for every command, a long path has to be given and can quickly become > > very irksome to the administrators. Hence the question about 'cd' with sudo. > > The problem is that 'cd' is a built-in to the command line shell. > > type -a cd > cd is a shell builtin This is highly OS/shell dependent... while some shells use an intrinsic, others actually call a script or similar. Since cd essentially, at some point, works on the current shell, any call to sudo will fork a separat process that, when it dies, leaves the parent shell unaffected. (in a nutshell, at least) > [...] > > Another possibility would be to create a script to do the common > tasks. The script would embed all of those long and inconvenient > paths and avoid the need for the users to type those in on the command > line. Think of the way that 'vipw', 'visudo', and others of that like > work. If you were editing a file you could create a script > 'edit_myfile' or some such and allow it sudo access. Agreed, this is pretty much what you'll have to do... or, as others have said, create a unique group with browse (read) priviledges for your directory structure. Also, symlinks are beautiful things, too... ;-) -- Russell M. Van Tassell russell at loosenut.com "We cannot be guilty of a greater act of uncharitableness, than to interpret the afflictions which befall our neighbors as punishments and judgments." -- Joseph Addison From Todd.Miller at courtesan.com Fri Jul 29 15:33:26 2005 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 29 Jul 2005 13:33:26 -0600 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: Your message of "Fri, 29 Jul 2005 12:13:28 PDT." <20050729191328.GC1210@loosenut.com> References: <20050729065025.GB1210@loosenut.com> <200507291356.TAA24376@harbour.india.hp.com> <20050729162019.GB24646@dementia.proulx.com> <20050729191328.GC1210@loosenut.com> Message-ID: <200507291933.j6TJXQhh027599@xerxes.courtesan.com> In message <20050729191328.GC1210 at loosenut.com> so spake Russell Van Tassell (russell+sudo-users): > This is highly OS/shell dependent... while some shells use an intrinsic, > others actually call a script or similar. Since cd essentially, at some > point, works on the current shell, any call to sudo will fork a separat > process that, when it dies, leaves the parent shell unaffected. (in a > nutshell, at least) I challenge you to find a Unix system where cd is *not* a shell builtin. It is true that some systems have a /usr/bin/cd command but that is due to POSIX requiring that all shell builtins have equialents in /usr/bin. It's not actually usable for anything and it actually relies on cd being a builtin in the first place. - todd From linux at alteeve.com Fri Jul 29 08:13:14 2005 From: linux at alteeve.com (Madison Kelly) Date: Fri, 29 Jul 2005 08:13:14 -0400 Subject: [sudo-users] Problem with 'sudo' ignoring switches Message-ID: <42EA1D5A.7020603@alteeve.com> Hi all, I've got a program (perl script) where I use 'sudo' to perform certain shell tasks. Most of the time this works fine but every now and then the 'sudo' prompts for a password regardless of the switches, which kills my running program because I can't enter the password from the shell even if I did assume users would know the password. Specifically how I use 'sudo': When I need to perform a priviledged task I call a small sub routine called 'prep_sudo' where I first enter: system "sudo -K\n"; To make sure there wasn't already a valid time stamp. Then I set the timestamp by entering: open (SUDO, '|sudo -S -v -p '.$say_sudo); print SUDO "$passwd\n"; close (SUDO); The initial '|' is supposed to tell 'sudo' to take the input from the script. The '-S -v -p ' is supposed to prompt from the password but also tell sudo to take the password from a shell. I use '-p ' to make the request look more like my program. When it works I then perform whatever task using 'sudo' I need and then as soon as I am done I enter: system "sudo -K\n"; Again to make sure that the timestamp is gone, keeping the period of time where 'sudo' is available as short as possible. 90% of the time this works perfectly. Every now and then though it seems to act like it didn't catch the switches. The reason I say this is because when this doesn't work my defined '-p ' is not printed and the default 'Password:' prompt is. Is there any know cases when 'sudo' ignores it's command line switches? I thought this might be a race condition so I tried adding a: 'sleep 1;' After killing the timestamp and before recreating the new timestamp but that didn't seem to help. Any advice would be much appreciated! Madison From Todd.Miller at courtesan.com Fri Jul 29 21:14:43 2005 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 29 Jul 2005 19:14:43 -0600 Subject: [sudo-users] Problem with 'sudo' ignoring switches In-Reply-To: Your message of "Fri, 29 Jul 2005 08:13:14 EDT." <42EA1D5A.7020603@alteeve.com> References: <42EA1D5A.7020603@alteeve.com> Message-ID: <200507300114.j6U1Eha3030928@xerxes.courtesan.com> Personally, I would do it like this: system("sudo -K"); ... $pid = open(SUDO, "|-"); if (!defined($pid)) { die "$0: can't fork: $!\n"; } elsif ($pid) { print SUDO "$passwd\n"; close(SUDO); } else { exec("sudo", "-S", "-v", "-p", $say_sudo); } That way $say_sudo can contain whitespace without worrying about quoting issues. - todd From discard at dawes.za.net Fri Jul 29 11:38:32 2005 From: discard at dawes.za.net (Rogan Dawes) Date: Fri, 29 Jul 2005 17:38:32 +0200 Subject: [sudo-users] Problem with CD command while using sudo In-Reply-To: <200507291356.TAA24376@harbour.india.hp.com> References: <200507291356.TAA24376@harbour.india.hp.com> Message-ID: <42EA4D78.9040106@dawes.za.net> Mousumi Kadham wrote: > > Hi , > > Here is the situation. There are certain commands to be executed, files to > be edited in a protected directory which has a long path. Without sudo and > every one using root, administrators simply will do cd to the final > directory and do many things like editing a few files etc. However with > sudo, for every command, a long path has to be given and can quickly become > very irksome to the administrators. Hence the question about 'cd' with sudo. > > Pls. help. > > Regards, > Mousumi > As mentioned, cd makes changes to the environment of the particular shell that calls it. However, sudo creates a new shell/environment when changing privileges, so the change that cd makes is immediately lost, when the sudo terminates. You need to rethink how your administrators will work . . . Sorry Rogan