On Sat, Jan 06, 2001 at 08:48:09PM +0100, Richard Levitte - VMS Whacker wrote:
> From: Lutz Jaenicke <[EMAIL PROTECTED]>
> Lutz.Jaenicke> On Fri, Jan 05, 2001 at 09:49:56PM +0100, Richard Levitte - VMS
>Whacker wrote:
> Lutz.Jaenicke> I don't know how select() would act on a regular
> Lutz.Jaenicke> file. /dev/random (and/or /dev/urandom) are no regular
> Lutz.Jaenicke> files, so we could first call stat() and only continue
> Lutz.Jaenicke> when S_ISCHR() is true (character device).
>
> My question about regular files was with the thought that one could
> hack RAND_load_file() with something similar.
While I had a look into the Linux manpage but did not find things discussed,
I know had a look into the HP-UX manpage for select():
...
The select() function supports regular files, terminal and pseudo-
terminal devices, STREAMS-based files, FIFOs and pipes. The behaviour
of select() on file descriptors that refer to other types of file is
unspecified.
...
I don't know, whether handling regular files is so much "standard", that
it is just not mentioned in other places. So let's rephrase the question:
Does somebody know of an (UNIX-like) OS _not_ supporting select() on
regular files?
> Lutz.Jaenicke> Hmm, I would consider using non-blocking
> Lutz.Jaenicke> reads. Select() does not know how many bytes you intend
> Lutz.Jaenicke> to read, so it will return "available" if just one byte
> Lutz.Jaenicke> is there and the second byte will block. Of course we
> Lutz.Jaenicke> could read byte-per-byte...
>
> That is a solution, but if we want to do reads with a timeout (say
> 20ms), that would mean a loop with a polling read with a definitely
> higher frequency than we wold get with a select(). On the other hand,
> non-blocking doesn't stop us from select()ing, does it? Hmm, perhaps
> it's a thought after all...
Select() and non-blocking read() are a perfect pair :-)
> Lutz.Jaenicke> This brings me to related point. Would it make sense to
> Lutz.Jaenicke> define a "default" place to look for an egd-socket? I
> Lutz.Jaenicke> had several contacts with people using my prngd (egd
> Lutz.Jaenicke> replacement) that installed prngd and did expect
> Lutz.Jaenicke> openssl to magically find it.
>
> That would be a good idea, I think. Personally, I'd say
> /etc/.egd-socket rather than /etc/egd-socket. This removes some
> possibilities for "accidents" as well. Yes, this is security by
> obscurity...
Hmm, I don't like "dot" files for a wanted functionality. Users may
want to use it anyway (e.g. when creating a keypair for their personal
keys). Providing entropy should be a system's task (provided by either
the OS or a process installed by the admin), so why not have it visible.
The possibility of a name clash may be given, but the only thing I would
expect to see behind "egd-socket" would be an egd-socket :-)
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
