Thanks to Frank Wortner and Sean O'Connell for quick replies!
Frank put it best...
>Actually, it's not an uncommon request -- it seems -- from database
>products. Informix, for example, wants the same device, but they call
it
>"/dev/sysdev0." In fact, if you look in the MAKEDEV script in /dev, you
>will see an entry for "sysdev," so it is part of the OS. (I'm not sure
why
>Oracle chooses to call it "/dev/timedev.") Look in conf.h, and you won't
>see a "timedev" device, but you will see a "sysdev" device.
>
>The default is to create it owned by root with read/write permissions for
>the owner, and read only for everyone else. With this set of
permissions,
>only root could conceivably alter any parameters via this file, although
>anyone could read whatever information this device supplies.
>
>If you look in /usr/sys/include/kern/sysdev_info.h, you will see that the
>device does indeed provide a time source which can be mapped into a
>process's address space.
Why couldn't ORACLE have used the sysdev device on DU/TU?
Ahhh, well...
--CHRis
[original message]
Managers, especially those with internals and/or security knowlege:
As a guru in training, I am at a loss here and need advice.
We are installing ORACLE Application Server V4 and encountered an error
during the orainst process.
ORACLE tech support has responded that we need to execute "mknod
/dev/timedev c 15 0" to create a device special file for direct access to
the realtime clock. I have tried to confirm that major-number 15 is indeed
the realtime clock, but without success so far. The mknod man page refers
to conf.c but there is mo mention of realtime clock in there.
Is this legit? Could it cause a security breach? Any other issues I
should be aware of?
If all this is indeed the case, it seems harmless enough.
Received on Fri Apr 28 2000 - 13:57:24 NZST