[EMAIL PROTECTED] writes:
> Yes, let's talk about error codes. There is another bug in the way errors
> are returned by rx. In the file server at least, the server simply returns
> a Unix errno to indicate an error. The problem is that errnos are not the
> same across different implementations of Unix. ENOTEMPTY, for example, is
> 64 on some machines and 66 on others. I was very confused the first time I
> saw "Identifier removed" (some kind of system V streams thing) being
> returned by the file server.
We did try to make the file server error codes more canonical in 3.2,
as I recall (maybe it was for 3.3). I wouldn't be surprised to learn
that we only did this for errnos which actually differ on
Transarc-supported platforms, however, and not in a completely general
sense. I think AIX has the most errnos which differ from those of the
the other vendors. The most frequently encountered example was EDQUOT.
[EMAIL PROTECTED] writes:
> You don't want to get too precise. Unix traditionally makes no distinction
> between "unknown user" and "wrong password," and even goes so far as to
> insert a fake delay to simulate the password decryption when you enter a bad
> user name. This is so crackers don't get any clues as to whether they've
> entered a valid user name or not. I wouldn't automatically assume that the
> null error message is a bug.
Argh. This is a cheap attempt to bolster weak security. If a security
system requires two passwords, implement dual passwords, but don't
pretend that a non-secret login id is a secret. Of course, there's
little difference between dual passwords and double-length passwords. Argh*2.
> In our case, you can always verify a uniqname through other means, so the
> null error message doesn't enhance our security all that much. But as an
> extreme example, you wouldn't want an error message that says, "the password
> you entered is too short by three characters, and the second character is
> wrong."
In stock AFS you can always verify user names through other means, so
the null error message isn't much good anywhere.
The security of Kerberos authentication as well as standard Unix
authentication depends heavily on the quality of the passwords chosen.
When in doubt, use a longer password, or a sentence, or something.
Lyle Transarc 707 Grant Street
412 338 4474 The Gulf Tower Pittsburgh 15219
