From torsten at canonical.com Mon Jan 4 04:43:24 2010 From: torsten at canonical.com (Torsten Spindler) Date: Mon, 04 Jan 2010 10:43:24 +0100 Subject: [sudo-users] Bug 378: no_proxy environment variable and others Message-ID: <1262598204.2458.17.camel@spitfire> Hello, start of December I filed a bug on passing through the complete proxy environment when using sudo, see also Bug 378 - Patch for passthrough of complete proxy environment As there's no update on the bug status or discussion of it in the bug tracker, I'm using this mailing list to gather information on the bug's status. I hope this an ok use for the list. Regards, Torsten From chuck.carson at gmail.com Tue Jan 5 15:09:49 2010 From: chuck.carson at gmail.com (Chuck) Date: Tue, 5 Jan 2010 14:09:49 -0600 Subject: [sudo-users] Sudo Config File Error?!? Message-ID: <3be30bc51001051209n9af5c79s2ece7a2a3dc23c9e@mail.gmail.com> I am building a sudo config on a Solaris 10 (update 8) system running sudo 1.7.2p1... Here is what I have so far: root ALL=(ALL) ALL %ng ALL=(ALL) ALL Cmnd_Alias SHELLS = /bin/sh, /bin/ksh, /bin/bash, /bin/csh, /usr/bin/sh, /usr/bin/ksh, /usr/bin/bash, /usr/bin/csh User_Alias CLUSTER100_USERS = oracle User_Alias DBA_USERS = +dba-users Host_Alias CLUSTER100_HOSTS = xxxx007, xxxx008 DBA_USERS CLUSTER100_HOSTS = (oracle) SHELLS CLUSTER100_USERS CLUSTER100_HOSTS = (root) SETENV: \ /opt/csw/bin/viewcronlog, \ /opt/csw/bin/viewcronolog, \ /ora_bin/base/oraInventory/orainstRoot.sh, \ /ora_bin/base/dbhomes/oracle/10A/root.sh, \ /ora_bin/base/dbhomes/oracle/10A/bin/srvctl, \ /ora_bin/crs/root.sh, \ /ora_bin/crs/bin/crsctl, \ /ora_bin/crs/bin/ocrconfig, \ /ora_bin/crs/install/root102.sh, \ /ora_bin/crs/OPatch/opatch, \ /bin/chown root:oinstall /ora_admin/rac/ocr, \ /bin/chown root:oinstall /ora_redoa/rac/ocr, \ /bin/chown oracle:oinstall /ora_admin/rac/votedisk, \ /bin/chown oracle:oinstall /ora_redoa/rac/votedisk, \ /bin/chown oracle:oinstall /ora_temp/rac/votedisk, \ /bin/chmod 640 /ora_redoa/rac/ocr, \ /bin/chmod 640 /ora_admin/rac/ocr, \ /usr/bin/sh /home/orabackup/orasoftware/Oracle10gR2/ 10.2.0.4/patch_bundles/Oct2009/8833280/psu_root.sh, \ /usr/bin/cp /home/oracle/scripts/crs/crs_stat.ksh /ora_bin/crs/bin/, \ /usr/bin/cp /home/oracle/scripts/crs/crs_stat.ksh /ora_bin/base/dbhomes/oracle/10A/bin/, \ /usr/bin/mv /ora_bin/crs/OPatch /ora_bin/crs/OPatch_102043, \ /usr/bin/cp -p /home/orabackup/orasoftware/OPatch_10.2.0.4.8/p6880880_102000_SOLARIS64.zip /ora_bin/crs/, \ /usr/bin/unzip /ora_bin/crs/p6880880_102000_SOLARIS64.zip, \ /ora_bin/crs/OPatch/ocm/bin/emocmrsp When I edit the file using visudo and then exit, I complains: visudo: /usr/local/etc/sudoers.tmp unchanged >>> /usr/local/etc/sudoers: syntax error near line 55 <<< visudo: Warning: unused User_Alias CLUSTER100_USERS What now? Here are lines 54-56 /ora_bin/crs/install/root102.sh, \ /ora_bin/crs/OPatch/opatch, \ /bin/chown root:oinstall /ora_admin/rac/ocr, \ Using "cat -vet" I look for non-printing characters in sudoers and I see everything as it should be.. (tabs, whitespace, and eol) This same stanza works on a Solaris 9 system running sudo 1.6.9p15 I then thought maybe there is a character limit on each definition but there are 578 bytes in the entry up to line 55 which seems to be an odd number to limit a line length at. (the entire entry has 1863 bytes) I'm sure this is something stupid staring me right in the face but I give up. Anyone have any ideas? Thanks, CC From Todd.Miller at courtesan.com Tue Jan 5 17:41:29 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 05 Jan 2010 17:41:29 -0500 Subject: [sudo-users] Sudo Config File Error?!? In-Reply-To: Your message of "Tue, 05 Jan 2010 14:09:49 CST." <3be30bc51001051209n9af5c79s2ece7a2a3dc23c9e@mail.gmail.com> References: <3be30bc51001051209n9af5c79s2ece7a2a3dc23c9e@mail.gmail.com> Message-ID: <201001052241.o05MfT4t027103@core.courtesan.com> I believe it will parse if you escape the ':' in the chown line. E.g. /bin/chown oracle\:oinstall /ora_admin/rac/votedisk, - todd From slawek at lach.art.pl Sun Jan 10 06:54:41 2010 From: slawek at lach.art.pl (slawek) Date: Sun, 10 Jan 2010 12:54:41 +0100 Subject: [sudo-users] Solution for timestamp matters. Message-ID: <1263124481.6382.15.camel@linux-9ona.site> Hi. I have idea to making sudo saver. The main problem is timestamp. It was great, because I don't must type any time my password, but it also insecure. Main distribution provide invention with key tray icon. After click on it, timestamp will be removed. I think, we must do more think. The ideal solution is providing central database for current session with some think like login/passwords, but for programs. Database with passwords and logins for session will be only accessible for root. When program/user invokes: sudo sessionopen identifier [password] Sudo will asks user to accept this identifier, select privileges and sudo behaviour. After that, user must type password according to sudo settings(root password or current user password). Possible settings are: 1. Invoking command for account - Delaying each command, showing that command in tray(most secure). User can prevent to doing tools any think and removing account for program, by clicking disallow. - Normal behaviour - command will invokes normally - Simulation(in future) - command will not be really invokes, but invokes only in chroot sandbox with AUFS enabled. 2. Privileges level: - User - command will only invokes commands enabled for current user, user password needed - Administrative - user must input administrator password - command may do any think - Others If command is disallowed, user may input administrative password. If some command(or user invokes): sudo sessionopen installing_firefox (without password) We only asks for accept(with prompting password) identifier and sets default options for this id(delaying each command). The delay time should be 10 seconds. Use cases: I have read on some web pages about way to install newest version of Firefox, so i prompt: sudo sessionopen installing_firefox Next, I input my(on Ubuntu) password. Each command like: sudo --use-id=installing_firefox [command] Will be processing for some period of time, so I can correct misspelling or drop privileges any time. It will be very intuitive and secure way. Programs, which don't know about identification and passwords for it, will not use sudo at the time, where I doing administrative task. From JR.Aquino at citrixonline.com Wed Jan 20 22:46:08 2010 From: JR.Aquino at citrixonline.com (JR Aquino) Date: Wed, 20 Jan 2010 19:46:08 -0800 Subject: [sudo-users] sudo + ldap + high cpu and recursive group member searching. Message-ID: <9393B40C-E0C1-418C-A3E4-73987F822A4C@citrixonline.com> Hello everyone. I have been chasing down a high cpu issue for several days now, and was hoping I could get some answers from the list regarding exactly how sudo performs its ldap searching. I have a large fleet of nss_ldap based linux servers and I have a selection of ldap(edirectory) servers. We have sudoRole objects defined which have the following sudo related attributes defined: sudoCommand sudoHost sudoUser When I perform a sudo and look at the verbose logging of my ldap server, I see that sudo does a search to find the group that I am a member of. Presumably because i have a sudoUser: username inside of this group. What I did not expect to see, is that sudo then appears to iterate down ALL the members of the (sudoRole) group I belong to. It appears to be requesting the following for each member: scope:0 dereference:0 sizelimit:1 timelimit:5 attrsonly:0 filter: "(objectclass=*)" attribute: "uid" attribute: "uniqueMember" attribute: "objectClass" Is this expected behavior for sudo? What is the official search expectations of sudo regarding ldap environments? I would think I could get the info I would be looking for by doing a search in the SUDOers group, with the search of: sudoUser=username, asking the attributes of sudoHost, sudoCommand, and sudoOptions... Could someone please clarify for me? Thank you. From Todd.Miller at courtesan.com Thu Jan 21 08:04:49 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Thu, 21 Jan 2010 08:04:49 -0500 Subject: [sudo-users] sudo + ldap + high cpu and recursive group member searching. In-Reply-To: Your message of "Wed, 20 Jan 2010 19:46:08 PST." <9393B40C-E0C1-418C-A3E4-73987F822A4C@citrixonline.com> References: <9393B40C-E0C1-418C-A3E4-73987F822A4C@citrixonline.com> Message-ID: <201001211304.o0LD4n27013740@core.courtesan.com> You don't specify what version of sudo you are running but I'll explain what the current version of sudo (1.7.2p2) does; older versions are similar. Sudo performs a query for all sudoRole entries that match the user, one of the user's groups or ALL. It may also query sudoRoles entries that have a netgroup in them. It then iterates over the answers and matches based on hostname, runas user, and command. It is not possible to just return entries with a specific command since sudo has very flexible matching rules. The host may be specified by name, by ip address, by network/netmask, by netgroup or ALL. The runas user can be specified by user name, user id, Unix group, netmask, or ALL. Command matching is done based on the device and inode of the file on disk, also there may be wildcard matching. - todd From JR.Aquino at citrixonline.com Thu Jan 21 08:17:24 2010 From: JR.Aquino at citrixonline.com (JR Aquino) Date: Thu, 21 Jan 2010 05:17:24 -0800 Subject: [sudo-users] sudo + ldap + high cpu and recursive group member searching. In-Reply-To: <201001211304.o0LD4n27013740@core.courtesan.com> References: <9393B40C-E0C1-418C-A3E4-73987F822A4C@citrixonline.com> <201001211304.o0LD4n27013740@core.courtesan.com> Message-ID: I understand that ldap doesn't return values in alpha order, but is it really expected for sudo to iterate over all of the users in my group after it has found me? Isn't there a way to have it stop on me? Again, I am seeing the previously mentioned attributes being requested... Member being one of them On Jan 21, 2010, at 5:04 AM, "Todd C. Miller" wrote: > You don't specify what version of sudo you are running but I'll > explain what the current version of sudo (1.7.2p2) does; older > versions are similar. > > Sudo performs a query for all sudoRole entries that match the user, > one of the user's groups or ALL. It may also query sudoRoles entries > that have a netgroup in them. It then iterates over the answers > and matches based on hostname, runas user, and command. > > It is not possible to just return entries with a specific command > since sudo has very flexible matching rules. The host may be > specified by name, by ip address, by network/netmask, by netgroup > or ALL. The runas user can be specified by user name, user id, > Unix group, netmask, or ALL. Command matching is done based on the > device and inode of the file on disk, also there may be wildcard > matching. > > - todd From JR.Aquino at citrixonline.com Thu Jan 21 18:39:47 2010 From: JR.Aquino at citrixonline.com (Jr Aquino) Date: Thu, 21 Jan 2010 15:39:47 -0800 Subject: [sudo-users] sudo + ldap + high cpu and recursive group member searching. In-Reply-To: <201001211304.o0LD4n27013740@core.courtesan.com> References: <9393B40C-E0C1-418C-A3E4-73987F822A4C@citrixonline.com> <201001211304.o0LD4n27013740@core.courtesan.com> Message-ID: Hello again Todd, Thank you very much for your explanation. I looked back over my ldap db debugging and compared it to the sudoers_debuging and correlated that sudo isn't actually doing the huge number of iteration lookups that I am seeing. The following search data appears to be happening as a Consequence of running sudo and it does this for each 'uniqueMember' returned from a search from gidMember associated with the initiating user: scope:0 dereference:0 sizelimit:1 timelimit:5 attrsonly:0 filter: "(objectclass=*)" attribute: "uid" attribute: "uniqueMember" attribute: "objectClass" I understand that some things that sudo does when it gets used, causes -re-initialization- of different types of environmental variables, etc. I.E. sudo -s would cause .bash_profile to be reread, and would probably also re-request the uid/gid information? Todd, if you have any understanding of nss_ldap or the initgroup() or inituser() functions... are you aware of any valid reason why a system, after exec'ing sudo, would try to re-enumerate the user's group, then do an iterative search for all the other members of that group for 'uid, groupMembership, and objectclass'? If that goes way beyond a sudo discussion, I thoroughly understand. I thought since this activity seems to be taking place as a consequence of running sudo, you may have seen it in the past during development. Thank you very very much Todd. -Jr On Jan 21, 2010, at 5:04 AM, Todd C. Miller wrote: > You don't specify what version of sudo you are running but I'll > explain what the current version of sudo (1.7.2p2) does; older > versions are similar. > > Sudo performs a query for all sudoRole entries that match the user, > one of the user's groups or ALL. It may also query sudoRoles entries > that have a netgroup in them. It then iterates over the answers > and matches based on hostname, runas user, and command. > > It is not possible to just return entries with a specific command > since sudo has very flexible matching rules. The host may be > specified by name, by ip address, by network/netmask, by netgroup > or ALL. The runas user can be specified by user name, user id, > Unix group, netmask, or ALL. Command matching is done based on the > device and inode of the file on disk, also there may be wildcard > matching. > > - todd From jepeway at blasted-heath.com Wed Jan 27 20:31:44 2010 From: jepeway at blasted-heath.com (Chris Jepeway) Date: Wed, 27 Jan 2010 20:31:44 -0500 Subject: [sudo-users] sudo support for more than one ldap-base In-Reply-To: <1Na9wU-1nzZxY0@fwd03.aul.t-online.de> References: <1Na9wU-1nzZxY0@fwd03.aul.t-online.de> Message-ID: > Hello Chris, Hey, Chris :) > I have tested the latest ldap based sudo in a very complex > environment. Oh, my. My involvement with sudo predates its LDAP support (it stopped about 15 years ago, actually), so there's not much I can help you with, there. I've cc'ed the appropriate list for these sorts of questions, so perhaps someone on it (Todd?) could give you a notion about implementing the feature you describe: > Because of several technical restrictions it is necessary to have > more then one searchbase > > Usually for other entries (e.g. pam, users, groups and other > databases in ldap) I have for each at least one entry. > Unfortunately for sudo this does not work. > For example: If I have two entries in /etc/ldap.conf: > sudoers_base ou=sudoers,dc=back,dc=storage > sudoers_base ou=sudoers,dc=global > Only one entry works. > > Do you think that this feature can also be supported by sudo in the > future? > When do you think this feature could be available? As I wrote, I'm not involved with sudo's implementation any longer, but the primary developer/maintainer/author is Todd Miller, and I'm sure he'll chime in. > regards > Chris ;-) Chris. From spinler.patrick at mayo.edu Thu Jan 28 17:50:01 2010 From: spinler.patrick at mayo.edu (Patrick Spinler) Date: Thu, 28 Jan 2010 16:50:01 -0600 Subject: [sudo-users] Sudo performance with LDAP netgroups in /etc/sudoers In-Reply-To: <4B6211D4.7090803@mayo.edu> References: <4B6211D4.7090803@mayo.edu> Message-ID: <4B621499.9060504@mayo.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bugger. My apologies, I forgot some more critical information. Much of my testing was on the RHEL supplied versions of sudo, Sudo version 1.6.9p17 on my redhat 5.3 box, and Sudo version 1.6.7p5 on my RHEL 4.8 box. However, I've also compiled and tried Sudo version 1.7.2p1 on RHEL 4, and see almost identical performance characteristics as the 1.6.* versions on the same host. So unfortunately whatever's going on here seems to be the same in the latest versions of sudo. Thanks! - -- Pat Patrick Spinler wrote: > > Hi all sudo knowledge gods. :-) I'd like to place a sudo performance > question before you. > > We have an environment (using redhat enterprise linux 5.3 as my test > box) where I am using netgroups in my sudoers, like so: > > +netgroup ALL=(ALL) NOPASSWD: ALL > > and direct my netgroup database to use LDAP via /etc/nsswitch.conf, like so: > > netgroup: files ldap > > Unfortunately, in my test box, I'm seeing abysmal performance invoking > sudo, on the order of 4 seconds to run a "sudo -l" > > I've established a very strong correlation between the number of > netgroups listed in /etc/sudoers and the invocation time. On my test > machine, with 15 netgroups listed, I had the 4 second invocation time > I just mentioned. When I reduced the number of netgroups to 7 by > combining lines using line continuation characters, my "sudo -l" time > dropped to an average 2.2 seconds over 10 tests. > > Sure enough, when I examined my ldap server logs, I see an ldap search > for each listing of a netgroup in /etc/sudoers directly resulting from > any invocation of sudo. This includes several searches for the same > netgroup per invocation if the netgroup is listed multiple times. E.g. > this: > > +netgroup ALL=(root) /bin/su - tomcat > +netgroup ALL=(tomcat) ALL > > would produce two searches for with the ldap filter > "(&(objectClass=nisNetgroup)(cn=netgroup))" on my servers. > > However, while there is a strong correlation between the number of ldap > searches and the experienced delay, that's not the whole story. My ldap > servers are, in fact, quite fast. I can run the following search (yes, > the duplication is intentional, intended to mirror the duplicate > netgroups in sudoers like above): > > time for i in netgr1 netgr2 netgr2 netgr3 netgr3 netgr4 netgr4; do > ldapsearch -x "(&(objectClass=nisNetgroup)(cn=$i))" > done > /dev/null > > in, on average, 0.14 seconds. > > So, for 7 netgroups, it's a fair assumption that my 2.2 second "sudo -l" > spends < .2 seconds searching ldap for netgroups, and about 2 seconds > doing "something else". > > Frustratingly, I haven't been able to profile this. The command: > > time strace sudo -l > > ends up complaining that: > > write(2, "sudo: ", 6sudo: ) = 6 > write(2, "must be setuid root", 19must be setuid root) = 19 > write(2, "\n", 1 > > and so gives no useful information. :-( > > Can anyone offer advice in tracing down the source of my delay? > > Thanks! > -- Pat > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktiFJkACgkQNObCqA8uBsxFqACcCyHUcpClZ5QS/8sxaQHMHsiS jNcAn1KRf9+qW5VIwXnNzNChYoHqq+nK =kOh4 -----END PGP SIGNATURE----- From spinler.patrick at mayo.edu Thu Jan 28 17:38:12 2010 From: spinler.patrick at mayo.edu (Patrick Spinler) Date: Thu, 28 Jan 2010 16:38:12 -0600 Subject: [sudo-users] Sudo performance with LDAP netgroups in /etc/sudoers Message-ID: <4B6211D4.7090803@mayo.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all sudo knowledge gods. :-) I'd like to place a sudo performance question before you. We have an environment (using redhat enterprise linux 5.3 as my test box) where I am using netgroups in my sudoers, like so: +netgroup ALL=(ALL) NOPASSWD: ALL and direct my netgroup database to use LDAP via /etc/nsswitch.conf, like so: netgroup: files ldap Unfortunately, in my test box, I'm seeing abysmal performance invoking sudo, on the order of 4 seconds to run a "sudo -l" I've established a very strong correlation between the number of netgroups listed in /etc/sudoers and the invocation time. On my test machine, with 15 netgroups listed, I had the 4 second invocation time I just mentioned. When I reduced the number of netgroups to 7 by combining lines using line continuation characters, my "sudo -l" time dropped to an average 2.2 seconds over 10 tests. Sure enough, when I examined my ldap server logs, I see an ldap search for each listing of a netgroup in /etc/sudoers directly resulting from any invocation of sudo. This includes several searches for the same netgroup per invocation if the netgroup is listed multiple times. E.g. this: +netgroup ALL=(root) /bin/su - tomcat +netgroup ALL=(tomcat) ALL would produce two searches for with the ldap filter "(&(objectClass=nisNetgroup)(cn=netgroup))" on my servers. However, while there is a strong correlation between the number of ldap searches and the experienced delay, that's not the whole story. My ldap servers are, in fact, quite fast. I can run the following search (yes, the duplication is intentional, intended to mirror the duplicate netgroups in sudoers like above): time for i in netgr1 netgr2 netgr2 netgr3 netgr3 netgr4 netgr4; do ldapsearch -x "(&(objectClass=nisNetgroup)(cn=$i))" done > /dev/null in, on average, 0.14 seconds. So, for 7 netgroups, it's a fair assumption that my 2.2 second "sudo -l" spends < .2 seconds searching ldap for netgroups, and about 2 seconds doing "something else". Frustratingly, I haven't been able to profile this. The command: time strace sudo -l ends up complaining that: write(2, "sudo: ", 6sudo: ) = 6 write(2, "must be setuid root", 19must be setuid root) = 19 write(2, "\n", 1 and so gives no useful information. :-( Can anyone offer advice in tracing down the source of my delay? Thanks! - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktiEdQACgkQNObCqA8uBsyWqgCfRzbL0vpo4HKsaOXteqlGPZLW ZEwAnRT2KJEvy64W9maBbYXxdQOXwWWd =P265 -----END PGP SIGNATURE----- From spinler.patrick at mayo.edu Thu Jan 28 22:02:25 2010 From: spinler.patrick at mayo.edu (Patrick Spinler) Date: Thu, 28 Jan 2010 21:02:25 -0600 Subject: [sudo-users] Sudo performance with LDAP netgroups in /etc/sudoers In-Reply-To: <4B621499.9060504@mayo.edu> References: <4B6211D4.7090803@mayo.edu> <4B621499.9060504@mayo.edu> Message-ID: <4B624FC1.4090601@mayo.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for continuing to follow up to myself. I've managed, with some advice, to track down a likely culprit, and it's all in our configuration. Our clients appear to experience some not insignificant delay negotiating TLS encryption on the ldap channel. When I turn tls off in my /etc/ldap.conf, my "sudo -l" times reliably fall to about 0.5 seconds. That's something very tolerable. Now, I just need to figure out if there's a way to improve that. Unfortunately for me, we can't just drop TLS/SSL Thanks anyway. - -- Pat Patrick Spinler wrote: > > Bugger. My apologies, I forgot some more critical information. > > Much of my testing was on the RHEL supplied versions of sudo, Sudo > version 1.6.9p17 on my redhat 5.3 box, and Sudo version 1.6.7p5 on my > RHEL 4.8 box. > > However, I've also compiled and tried Sudo version 1.7.2p1 on RHEL 4, > and see almost identical performance characteristics as the 1.6.* > versions on the same host. > > So unfortunately whatever's going on here seems to be the same in the > latest versions of sudo. > > Thanks! > -- Pat > > Patrick Spinler wrote: >> Hi all sudo knowledge gods. :-) I'd like to place a sudo performance >> question before you. > >> We have an environment (using redhat enterprise linux 5.3 as my test >> box) where I am using netgroups in my sudoers, like so: > >> +netgroup ALL=(ALL) NOPASSWD: ALL > >> and direct my netgroup database to use LDAP via /etc/nsswitch.conf, like so: > >> netgroup: files ldap > >> Unfortunately, in my test box, I'm seeing abysmal performance invoking >> sudo, on the order of 4 seconds to run a "sudo -l" > >> I've established a very strong correlation between the number of >> netgroups listed in /etc/sudoers and the invocation time. On my test >> machine, with 15 netgroups listed, I had the 4 second invocation time >> I just mentioned. When I reduced the number of netgroups to 7 by >> combining lines using line continuation characters, my "sudo -l" time >> dropped to an average 2.2 seconds over 10 tests. > >> Sure enough, when I examined my ldap server logs, I see an ldap search >> for each listing of a netgroup in /etc/sudoers directly resulting from >> any invocation of sudo. This includes several searches for the same >> netgroup per invocation if the netgroup is listed multiple times. E.g. >> this: > >> +netgroup ALL=(root) /bin/su - tomcat >> +netgroup ALL=(tomcat) ALL > >> would produce two searches for with the ldap filter >> "(&(objectClass=nisNetgroup)(cn=netgroup))" on my servers. > >> However, while there is a strong correlation between the number of ldap >> searches and the experienced delay, that's not the whole story. My ldap >> servers are, in fact, quite fast. I can run the following search (yes, >> the duplication is intentional, intended to mirror the duplicate >> netgroups in sudoers like above): > >> time for i in netgr1 netgr2 netgr2 netgr3 netgr3 netgr4 netgr4; do >> ldapsearch -x "(&(objectClass=nisNetgroup)(cn=$i))" >> done > /dev/null > >> in, on average, 0.14 seconds. > >> So, for 7 netgroups, it's a fair assumption that my 2.2 second "sudo -l" >> spends < .2 seconds searching ldap for netgroups, and about 2 seconds >> doing "something else". > >> Frustratingly, I haven't been able to profile this. The command: > >> time strace sudo -l > >> ends up complaining that: > >> write(2, "sudo: ", 6sudo: ) = 6 >> write(2, "must be setuid root", 19must be setuid root) = 19 >> write(2, "\n", 1 > >> and so gives no useful information. :-( > >> Can anyone offer advice in tracing down the source of my delay? > >> Thanks! >> -- Pat > ____________________________________________________________ sudo-users mailing list For list information, options, or to unsubscribe, visit: http://www.sudo.ws/mailman/listinfo/sudo-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktiT8EACgkQNObCqA8uBszSZwCgpCC/dCMnHVXVDnfEbeIux2TB pVUAn1XKQakJdbEgo1Z8T8dTS2Qvl6wy =q3ac -----END PGP SIGNATURE----- From Vinay.HN at Lntemsys.com Sat Jan 30 05:26:57 2010 From: Vinay.HN at Lntemsys.com (Vinay HN) Date: Sat, 30 Jan 2010 15:56:57 +0530 Subject: [sudo-users] Problem during cross-compilation Message-ID: Hi, I'm trying to cross-compile "sudo" source for Power-PC platform using Montavista tool chain. I'm getting the following error message during configuration: checking host system type... Invalid configuration `ppc_82xx': machine `ppc_82xx' not recognized It is clear that it has found the cross-compiler and configure knows that we are cross-compiling but it fails to recognize the machine. The complete dump follows: [vhn at localhost sudo-1.7.2p2]$ ./configure --host=ppc_82xx configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. configure: Configuring Sudo version 1.7.2p2 checking whether to lecture users the first time they run sudo... yes checking whether sudo should log via syslog or to a file by default... syslog checking which syslog facility sudo should log with... local2 checking at which syslog priority to log commands... notice checking at which syslog priority to log failures... alert checking how long a line in the log file should be... 80 checking whether sudo should ignore '.' or '' in $PATH... no checking whether to send mail when a user is not in sudoers... yes checking whether to send mail when user listed but not for this host... no checking whether to send mail when a user tries a disallowed command... no checking who should get the mail that sudo sends... root checking for bad password prompt... Password: checking for bad password message... Sorry, try again. checking whether to expect fully qualified hosts in sudoers... no checking for umask programs should be run with... 0022 checking for default user to run commands as... root checking for editor that visudo should use... vi checking whether to obey EDITOR and VISUAL environment variables... no checking number of tries a user gets to enter their password... 3 checking time in minutes after which sudo will ask for a password again... 5 checking time in minutes after the password prompt will time out... 5 checking whether to use per-tty ticket files... no checking whether to include insults... no checking whether to override the user's path... no checking whether to get ip addresses from the network interfaces... yes checking whether stow should be used... no checking whether to use an askpass helper... no checking whether to do user authentication by default... yes checking whether to disable running the mailer as root... no checking whether to disable shadow password support... no checking whether root should be allowed to use sudo... yes checking whether to log the hostname in the log file... no checking whether to invoke a shell if sudo is given no arguments... no checking whether to set $HOME to target user in shell mode... no checking whether to disable 'command not found' messages... no checking whether to enable environment debugging... no checking for egrep... egrep checking for ppc_82xx-gcc... ppc_82xx-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ppc_82xx-gcc accepts -g... (cached) no checking for ppc_82xx-gcc option to accept ISO C89... none needed checking for library containing strerror... none required checking how to run the C preprocessor... ppc_82xx-gcc -E checking build system type... i686-pc-linux-gnu checking host system type... Invalid configuration `ppc_82xx': machine `ppc_82xx' not recognized configure: error: /bin/sh ./config.sub ppc_82xx failed If you have any suggestions, please let me know.