porting CCAPI to UNIX

[Ken Raeburn]

On May 2, 2007, at 18:25, Ken Hornstein wrote:
> I can only tell you what I did.  At login time our credential cache
> code creates a Unix domain socket (using socketpair()), uses dup2()
> to make the descriptor the maximum value possible (you look at the
> maximum number of descriptors available via getrlimit()) and use
> setrlimit to make the maximum descriptor one below that.  E.g, say
> the maximum descriptor value is 1023; you use dup2() to make your
> communication descriptor 1023, and use setrlimit() to make the
> maximum descriptor value 1022.  This doesn't _prevent_ processes
> from closing the descriptor, but in my experience they all stop
> closing descriptors at the maximum descriptor limit.  So all processes
> that are children of login get this descriptor in their environment
> and they use it to communicate with a credential cache server that
> is forked off as part of the login process (it's more complicated
> than that, but that's the key bit of magic).  This provides
> per-login-session semantics that seems to be pretty secure (of
> course it is not perfect).

Um...  That's an interesting approach.  As long as you've got that  
control over the login process.  Are you changing the hard or soft  
resource limit, or both?

> I've been using this in production for ... oh, almost three years
> now, on a wide variety of Unixes (off the top of my head: tons of
> different Linuxes, Solaris, AIX, HP/UX, Irix; it works fine on MacOS
> X but we prefer the CCAPI on that platform), and I am continually
> surprised how well it works.  We haven't had any problems with it.

Presumably you're using modified sshd and login programs, and maybe  
ftpd and other daemons that might need credentials (such as to get  
AFS tokens)?  Or you do have a PAM module or equivalent that gets the  
job done on all these systems?

> I admit that it's gross ... but if you can tell me of a portable
> solution that has the same semantics, I would love to hear about
> it.
>
> --Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

Ken