[1349] in testers
Re: New Login
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Dec 5 22:26:48 1990
From: dkk@ATHENA.MIT.EDU
Date: Wed, 5 Dec 90 22:26:21 -0500
To: amgreene@ATHENA.MIT.EDU
Cc: testers@ATHENA.MIT.EDU
In-Reply-To: Andrew Marc Greene's message of Tue, 4 Dec 90 19:35:17 -0500,
John Stephens suggested:
> It would be nice if the new login allowed users whose fileserver is
> down the opportunity to login to Athena anyway.
The login should just build a temporary home directory, as it always
has. If this is not the case, either it's a major change in
functionality or I'm just confused...
Andrew Greene further suggested:
> Generalizing, it might be useful to be able to log in even if a
> workstation can't get to Kerberos or Hesiod, without using root.
> Would adding a line to /etc/passwd.local containing a passwordless
> user "local" create problems?
I agree that such an account would be useful, as "root" is typically
used for this purpose now. But there are a few things we should
consider:
- Does this defeat the purpose of keeping the passwords for accounts
like testuser and mwm_user from becoming too public?
- Can we really allow a null password? At least having a password
like "please" would keep some of the riffraff off our systems.
- Should a "local" account be in the default /etc/passwd file?
My answers are:
- No, this doesn't have the same security risk as an rms-equivalent
Athena account, because it gets no Kerberos tickets. The posession
of Athena Kerberos tickets is sometimes sufficient to get
authorization to use an Athena service or to access Athena files.
- We shouldn't allow a null password. Even an obvious one is better.
- No, "local" shouldn't be in the default /etc/passwd.local file. If
we do this I'd suggest something like:
cat /etc/passwd.local /srvd/[...]/passwd.add > /etc/passwd
on workstations with PUBLIC=true. Otherwise, "mkserv remote" and
similar forms of privatization would result in a significant loss
of security. Users can be expected to change their root password
(though they may not do so), but we can't expect them to keep
working around new problems that we introduce for them.
