Roland Mainz writes:
> - Can I register a C function which gets called at shell shutdown which
> can be used to close any file descriptors ?
Atexit could do that ... but why? Descriptors are closed on shutdown
-- period. Unless I'm misunderstanding, you shouldn't have to do
anything special.
I would think that a bigger issue is having the existence of this
shell-internal file descriptor leak into the user's model of the
shell operation. Are you just doing open(2)? If so, then this is
probably fd 3 ... can the user read from fd 3 and get random numbers?
Can the user close it out from underneath you?
Or if the user tries to access this fd, do you dup2 it somewhere else?
Don't forget to set close on exec ...
> - How should I handle writing to ${RANDOM} (which normally defines the
> seed of |rand()|) when /dev/urandom is used ? The device is read-only on
> Solaris for normal users. Should a write failure (to /dev/urandom) be
> ignored or handled as error ?
I don't think there's really a good option available with just one
mechanism.
If you make $RANDOM "really random" by default, but revert to normal
seeded rand() mode when written to, then users will be confused. On
some platforms, reading from $RANDOM alone (without initializing) will
produce high quality random numbers. On other platforms, it'll
produce the worst-possible randomness. If smart users try to make
their applications robust by writing $$ (or some such) to $RANDOM,
they'll perversely end up with lower quality randomness by accident on
platforms that have /dev/urandom (which isn't just Solaris, but may
not be all platforms).
I think it'd be better to keep the default $RANDOM behavior, and
create a new $URANDOM defined to return higher-quality randomness
without initialization.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
