Shell weirdness

Habbie pointed me to this one, but I thought it would be wise to write this down for future reference. The shell source command (.) in bash (and others) works like exec, not like open, (which you might be confused to think) in that it searches your $PATH for the argument, and if it can’t find the argument in the $PATH, it looks in $PWD



$ echo “bin/meuk” > ~/bin/meuk
$ echo “home/meuk” > ~/meuk
$ cd ~

$ . meuk
$ source meuk

Update: Tested with bash / dash / ash / pdksh
All give the above result

From the manual:

source filename [arguments]
Read and execute commands from filename in the current shell
environment and return the exit status of the last command exeâ
cuted from filename. If filename does not contain a slash, file
names in PATH are used to find the directory containing fileâ
name. The file searched for in PATH need not be executable.
When bash is not in posix mode, the current directory is
searched if no file is found in PATH. If the sourcepath option
to the shopt builtin command is turned off, the PATH is not
searched. If any arguments are supplied, they become the posiâ
tional parameters when filename is executed. Otherwise the
positional parameters are unchanged. The return status is the
status of the last command exited within the script (0 if no
commands are executed), and false if filename is not found or
cannot be read.

Enabling the posix option in bash doesn’t change it’s behaviour, disabling sourcepath does:

$ shopt -u sourcepath
$ . meuk

Sudo with LDAP

Most people who use *nix systems are probably familiar with sudo. At a customer I’ve been working for there used to be a vast machine park with sudo installations, all slightly different in configuration. Maintaining these configurations was not an easy task. Enter LDAP. Using LDAP for storing the sudo configuration we can now have a single point for configuring sudo, with instant updates on all machines.
I’ll explain what needs to be done to ldap-i-fy your sudo configuration below.
sudo cartoon xkcd

Put the following schema in your ldap config

dn: cn=schema
attributeTypes: ( NAME 'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX X-ORIGIN 'SUDO' )
attributeTypes: ( NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX X-ORIGIN 'SUDO' )
attributeTypes: ( NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX X-ORIGIN 'SUDO' )
attributeTypes: ( NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX X-ORIGIN 'SUDO' )
attributeTypes: ( NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX X-ORIGIN 'SUDO' )
objectClasses: ( NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN 'SUDO' )

Restart your ldap server(s) to include the schema

Build sudo with the configure options ‘–with-ldap=<path$gt;’ and –with-ldap-conf-file=/etc/sudo.ldap

Put new sudo binaries on your system(s)

Create /etc/sudo.ldap with the following contents, replacing the ip’s and dc’s

sudoers_base ou=SUDOers,dc=example,dc=com

Create an ldif file with your sudo config (see below for an example)

dn: ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
description: SUDO Configuration Subtree
ou: SUDOers

dn: cn=defaults,ou=SUDOers,dc=example,dc=com
cn: defaults
sudooption: ignore_dot
sudooption: !mail_no_user
sudooption: !root_sudo
sudooption: log_host
sudooption: logfile=/var/log/sudolog
sudooption: !syslog
sudooption: timestamp_timeout=10
objectClass: top
objectClass: sudoRole
description: Default sudoOption’s

dn: cn=Rule1,ou=SUDOers,dc=example,dc=com
cn: Rule1
sudooption: !authenticate
objectClass: top
objectClass: sudoRole
sudohost: ALL
sudocommand: /some/command
sudocommand: /some/other/command
sudouser: ALL
description: Allowed without password for ALL users

The first block of code contains the container for the rest of the sudo configuration, just leave this as-is. The second block contains the default options for sudo. Configure these to your liking, they are the same as for the non-ldap config, and are documented in the manual-page.

The third code-block lists a sample sudo rule. Repeat these as often as needed. The fields ‘sudohost’, ‘sudocommand’ and ‘sudouser’ are required, ‘sudooption’ is optional, and can override the defaults specified above.

Sudocommand should be repeated for every single executable (or use wildcards, not recommended) you want to enable via sudo. Sudouser can take regular usernames, or unix-group names when prefixed by a percent sign (%).

Please note that although commands can be negated (!/some/binary) there are work-arounds, so please think before acting. Users and Hosts can NOT be negated using ldap-configs… this is a current limitation.