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 ---
Howdy folks,

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]"

Reply via email to