Greg A. Woods writes:
>> 1. Remote access for root with empty password
>> ---------------------------------------------
>> 
>> PR 664 is about rlogin and ftp being blocked if root has no password,
>> but rsh isn't. I clarified to the user that rlogin is now like rsh in
>> that it respects ~root/.rhosts. ftp was only blocked because of
>> /etc/ftpusers.
>> 
>> The submitter (David Sharnoff) still wants the functionality of prevented
>> root access if root's password is empty. I don't believe that this is
>> a special case that we need to support in r{sh,login} or ftp.
> 
> Of course.  He's right.  Root access should be prevented on any ttys
> that are not marked "secure", regardless of whether there's a password.
> Period.  (and of course this is one place where obscurity is necessary
> -- the reason for the denial should not be revealed)

ftpd isn't relevant WRT /etc/ttys; /etc/ftpusers is used as access
control there. Again for a null root password.

rlogind shouldn't enforce the `secure' setting in /etc/ttys.
Why? because there's nothing stopping
	# rsh remotemachine xterm
or even
	# rsh remotemachine /bin/csh -i
Both of these wouldn't (and shouldn't) honour /etc/ttys.

As to a null root password; maybe rlogind should specifically ignore
an empty root password *IFF* .rhosts wasn't used to authenticate...
I'll investigate this further.


>> 2. su(1) uses /etc/group instead of current grouplist
>> -----------------------------------------------------
>> 
>> PRs 792 and 2466 both mention that su(1) parses /etc/group for the
>> contents of gid 0 to determine if access is permitted to root.
>> If a user's primary group is 0, but they're not in /etc/groups, things
>> fail.
>> 
>> The suggested solution is to check the users' *current* group list
>> using getgroups() (both primary & supplimentary groups) for
>> existance of gid 0, instead of getpwent(getuid()) and getgrgid(0).
>> This is consistant with other access checks on the system...
> 
> I concur with some of the others who've commented on this and said that
> it's right the way it is....
> 
> I.e. the current method of requiring membership in "wheel" as listed in
> /etc/group is correct.  This is an access control mechanism unique to
> su(1) and it should not be consistent with other uses of gid 0.
> 
> In fact there should be no requirement for "wheel" to be gid 0 -- it
> should be possible to make it any old UID.


Actually, su makes its check against gid==0 not groupname==wheel.
This should probably be changed to using the symbolic name, and
setting up a -DDEFINE in the Makefile to allow overriding for sites
that prefer "sugroup" or whatever. That should fulfill your last
requirement. I'll look at this as well...

In any case, su has been changed to using the access list for the
current process. Even if su is recompiled to using "sugroup", I'd
still expect su check my *current* grouplist for "sugroup" access,
not what's in /etc/group...