I'm trying over here since I didn't have any luck fishing in ports@ :-)
I've since found the parts of the MIT login.krb5 that chown the
forwarded ticket file. That was nice to know to not really relevent :-)
I understand that there's a race condition when having root chown a file
in /tmp to a user (symlinks being the obvious attack path). There are
ways around that, though, so I don't believe the change that I'm looking
for leads to a security problem if handled carefully.
All programs evolve until they can send email.
- A.S.R. quote (Richard Letts)
Except Microsoft Exchange.
- A.S.R. quote (Art)
--- Begin Message ---
When using the MIT krb5 port (up to date as of a CVSup this morning) on
a recent -STABLE box, there are two ways to enable telnetd in
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user
telnet stream tcp nowait root /usr/local/krb5/sbin/telnetd telnetd -a user -L
The first way, according to the man page and to the README.FreeBSD
included in teh krb5 port, uses /usr/bin/login. The second way uses the
MIT login program.
The first way is obviously preferred -- you get login.conf and
login.access that way. However, when using forwarded tickets it creates
them with the wrong permissions (0600 root:wheel) and the user can't
even read their own ticket. If root chown's them to the user manually
the forwarded ticket works correctly.
Naturally, login.krb5 sets the permissions correctly.
Since a simple chown seems like such a simple thing to fix and there's
compelling benefits to using the FreeBSD login, I'd like to start using
/usr/bin/login with my MIT telnetd (it's even the default in the port
;-) ). But finding figuring out just where this should be down has been
My first instinct (supported by the wording in README.FreeBSD) was to
look in /etc/pam.conf. But PAM doesn't appear to be in play here: I have
pam_krb5.conf commented out and am still able to login in correctly!
Uncommenting pam_krb5 in the PAM stack appears to have no effect.
So my next instinct was that the MIT telnetd was performing the ticket
creation in /tmp itself. That's a much bigger piece of software to read
through -- I'm still digging into it.
Are there any known workarounds for this? Would someone with a bit more
familiarity with the code in question mind taking a look at it?
Belief gets in the way of learning.
- Robert Heinlein
--- End Message ---
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"