Actually there were two bugs:
- Add REG_NOTBOL after the first substitution.
- Handle the rm_so == rm_eo == 0 case, where in a substitution such
as 's/bzzzt/z*/g' the first time z* matches nothing.
The appropriate entry in /etc/group as returned by getgrnam() is
used to determine if 'su root' may be permitted, rather than
checking if membership exists in the result of getgroups().
The following changes were made regarding the behaviour of the special
group for 'su root'
* allow for definition of SUGROUP (defaults to "wheel") to override group name.
* use getgrnam(SUGROUP) instead of getgrgid(0).
* only scan getgrnam(SUGROUP)->gr_mem when checking for group membership.
* be more specific as to why 'su root' failed
NOTE: If a user's primary group is SUGROUP, and they're not a member
of SUGROUP in /etc/group, they will not be able to su.
auto-login ftp URL is used when $ftp_proxy is defined. It now prints:
Auto-login using ftp URLs isn't supported when using $ftp_proxy
Should solve rest of [bin/3643].
Whilst this is inconsistant with the behaviour when $ftp_proxy isn't
defined, the following constraints apply:
* it's not possible to support ftp URL auto-login when $ftp_proxy is
defined, since it uses http not ftp, and you can't `login' to http
servers; fudging this would require a major rewrite of ftp anyway)
* silently ignoring $ftp_proxy and not using it if an ftp auto-login
URL is given is bad user interface design)
* mrg & others will harrass me if I remove support for autologin ftp URLs
when $ftp_proxy isn't defined, even though it made the behaviour
consistant whether $ftp_proxy was set or not.
Only information leaks now are:
* if '-s -s' is used (only allow s/key users, and force s/key use),
then "login incorrect" will be given if a non-s/key user (or
non-existant user) attempts to login; no password will be prompted
for.
XXX: maybe this should be fixed, but further analysis is required.
* an s/key user will be reminded in the "Password" prompt that they
have an s/key. Therefore it would be possible to determine if a user
is active on the machine if they have an s/key.
XXX: maybe an option is required to control this behaviour
_PASSWORD_WARNDAYS from <pwd.h>). For non-root users, enforce expiry when
it happens. From Simon Gerraty <sjg@zen.void.oz.au> in [bin/935].
* Check for group 0 in process's current group membership (as returned by
getgroups(2)), instead of just looking at the entry for wheel in /etc/group.
Based on code by Dan Caresone <dan@oink.geek.com.au> in [bin/792], and
also solves [bin/2466].
* Clean up to pass -Wall
* if the user has an s/key, provide a reminder in the password prompt
* if '-s' is given once, force a user that has an s/key to use it
* if '-s' is given more than once, only permit s/key logins
- rsh/rcmd combinations don't die sometimes, and spin in poll loops
+ detect errors from read/write etc, don't ignore them in some cases
+ use INFTIM instead of 0 in poll
+ detect invalid file descriptors in poll
+ use varargs/stdarg as appropriate
+ use posix signal calls
+ EWOULDBLOCK -> EAGAIN
