... forgot to include info-afs on the cc...
------- Forwarded Message
Date: Sat, 1 May 1993 11:57:27 -0400
To: "Randall S. Winchester" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To: Randall S. Winchester's message of Sat, 1 May 1993 08:06:03 -0400,
<[EMAIL PROTECTED]>
Subject: Re: IP acl & system:authuser
From: "Richard Basch" <[EMAIL PROTECTED]>
What scenario are you trying to solve, exactly?
I have not yet found a scenario that requires that hosts be members of
system:authuser.
1. You can always create a group, system:campus, and add the hosts or
wildcarded hosts to that group and put that on the acl.
2. You can always put system:authuser on the acl.
The first will give you a weak protection of the software, from the
casual cracker (I can defeat something like that in minutes, which is
why I say it shouldn't be considered system:authuser).
The second will give you strong protection, because you have verified
the user's credentials, and you are assuming his password has not been
compromised (or the security registry). Machine's with srvtabs, if you
consider them relatively secure can authenticate themselves to the cell
by getting an afs key with their srvtab identity (from the Kerberos
server) - after all, a srvtab is basically a machine's password. (All
you need to do is register the srvtab identity in the ptserver.)
If you need user@host, you can always do something like:
system:hosts l
system:users r
This gives hosts a weak security access to look at the directory, and
the users a strong access to actually do anything useful. Even if
someone works around the weak level of security, they will not be able
to read any files. If one of those users does not try to subvert the
weak IP restrictions, they will only be able to read those files if they
are on one of the designated hosts.
So, basically, you have:
user restriction
host restriction
user & host restriction
This is why I question all claims that hosts should be a member of
system:authuser.
-Richard
------- End Forwarded Message
