RE: more inetd trouble

2001-11-21 Thread Hylton Tregenza

Hi 
I have come into this thread a bit late. Having just completed Inetd.d
/openssl I might be able to help butI do not have the original question.

Inetd uses stdin and stdout (0,1). I have noted that any debugging
indormation (printf etc) sent to these ports intereferes with the
comminication. In my implementation I am not using the bio functions but
was able to get away with 

SSL_set_rfd(pSSL, fileno(stdin));
SSL_set_wfd(pSSL, fileno(stdout));

to set up the reading and writing options of SSL

If I can help any more please let me know.

Hylton
I may be able to post portions of source code if it would be relevnt.


-Original Message-
From: Matthew Fleming [mailto:[EMAIL PROTECTED]]
Sent: 16 November 2001 05:45
To: [EMAIL PROTECTED]
Subject: more inetd trouble


Matthew Fleming [EMAIL PROTECTED] writes:
 But what I have written is, not a standalone server program, but a
 daemon which is invoked by inetd. It seems to me that this should
work
 the same as the standalone, except that the tcp_listen() and accept()
 calls should be unnecessary; inetd should hand the daemon a socket
 descriptor which should be usable in the BIO_new_socket call; and
this
 socket descriptor should be accessible as fd 0, 1, or 2 (inetd makes
all
 3 descriptors available, but there is really only one socket, so each
of
 the descriptors should refer to the same thing).

I'm not sure that it's safe to write file descriptor 0.

Have you tried creating one bio for reading on stdin and one
for writing on stdout and passing them both to SSL?

-Ekr

By this I assume you mean something like the following:

int sock,s;
-  BIO *sbio_in, *sbio_out;
SSL_CTX *ctx;
SSL *ssl;
int r;

/* Build our SSL context*/
ctx=initialize_ctx(KEYFILE,PASSWORD);
load_dh_params(ctx,DHFILE);
generate_eph_rsa_key(ctx);

 
SSL_CTX_set_session_id_context(ctx,(void*)s_server_session_id_context,
  sizeof s_server_session_id_context);
/*
sock=tcp_listen();

while(1){
  if((s=accept(sock,0,0))0)
err_exit(Problem accepting);
 */ 
 -   sbio_in=BIO_new_socket(0,BIO_NOCLOSE);
 -   sbio_out=BIO_new_socket(1,BIO_NOCLOSE);
  ssl=SSL_new(ctx);
 -   SSL_set_bio(ssl,sbio_in,sbio_out);

  if((r=SSL_accept(ssl)=0))
berr_exit(SSL accept error);


This still does not work with inetd. 

Actually I don't see why you should have to use 2 sbio objects when the
program is invoked by inetd, but can get away with one when the server
is invoked from the command line; it seems to me that it should be the
same either way.

I'm strictly an amateur, but I would think that the difference between
starting the program from the command line and from inetd shouldn't have
to do so much with the socket descriptors, but with the things that
inetd does *before* invoking the daemon (eg, Chapter 12, UNIX Network
Programming, Stevens).

--
Matthew Fleming, MD 
Associate Professor 
Dept. of Dermatology
Medical College of Wisconsin

E-mail: [EMAIL PROTECTED]
S-mail:
Dept. of Dermatology
Medical College of Wisconsin
8701 Watertown Plank Rd.
Milwaukee, WI 53226
Phone:414.456.4072 
Fax:414.456.6518

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



smime.p7s
Description: application/pkcs7-signature


more inetd trouble

2001-11-16 Thread Matthew Fleming

Matthew Fleming [EMAIL PROTECTED] writes:
 But what I have written is, not a standalone server program, but a
 daemon which is invoked by inetd. It seems to me that this should
work
 the same as the standalone, except that the tcp_listen() and accept()
 calls should be unnecessary; inetd should hand the daemon a socket
 descriptor which should be usable in the BIO_new_socket call; and
this
 socket descriptor should be accessible as fd 0, 1, or 2 (inetd makes
all
 3 descriptors available, but there is really only one socket, so each
of
 the descriptors should refer to the same thing).

I'm not sure that it's safe to write file descriptor 0.

Have you tried creating one bio for reading on stdin and one
for writing on stdout and passing them both to SSL?

-Ekr

By this I assume you mean something like the following:

int sock,s;
-  BIO *sbio_in, *sbio_out;
SSL_CTX *ctx;
SSL *ssl;
int r;

/* Build our SSL context*/
ctx=initialize_ctx(KEYFILE,PASSWORD);
load_dh_params(ctx,DHFILE);
generate_eph_rsa_key(ctx);

 
SSL_CTX_set_session_id_context(ctx,(void*)s_server_session_id_context,
  sizeof s_server_session_id_context);
/*
sock=tcp_listen();

while(1){
  if((s=accept(sock,0,0))0)
err_exit(Problem accepting);
 */ 
 -   sbio_in=BIO_new_socket(0,BIO_NOCLOSE);
 -   sbio_out=BIO_new_socket(1,BIO_NOCLOSE);
  ssl=SSL_new(ctx);
 -   SSL_set_bio(ssl,sbio_in,sbio_out);

  if((r=SSL_accept(ssl)=0))
berr_exit(SSL accept error);


This still does not work with inetd. 

Actually I don't see why you should have to use 2 sbio objects when the
program is invoked by inetd, but can get away with one when the server
is invoked from the command line; it seems to me that it should be the
same either way.

I'm strictly an amateur, but I would think that the difference between
starting the program from the command line and from inetd shouldn't have
to do so much with the socket descriptors, but with the things that
inetd does *before* invoking the daemon (eg, Chapter 12, UNIX Network
Programming, Stevens).

--
Matthew Fleming, MD 
Associate Professor 
Dept. of Dermatology
Medical College of Wisconsin

E-mail: [EMAIL PROTECTED]
S-mail:
Dept. of Dermatology
Medical College of Wisconsin
8701 Watertown Plank Rd.
Milwaukee, WI 53226
Phone:414.456.4072 
Fax:414.456.6518

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]