Re: onconfig file

Malcolm Weallans wrote: > The system administrator at my current site thought he would be very > clever and he linked the onconfig files to different directories using > ln -s. We have now discovered that these links are being lost when we > use onmonitor and replaced by a local file, but not when we use vi. Is > this yet another reason why we should not use onmonitor? Does anybody > else think that onmonitor still has a role in teaching IDS to > prospective admins? It is still documented in the manuals so > presumably it should still work. > > regards > > Malcolm > P.S. I am having to use google groups to post messages as info > security here has to be seen to be believed. I keep a central repository of onconfig files - by using symbolic links from the repository to the actual various INFORMIXDIR locations, precisely because of this problem. When I backup the central repository, I use a command that is oblivious to the symlinks and simply copies the files through the symlink (that is not tar, nor cpio, nor pax, but good old cp). OTOH, I keep a central sqlhosts file with symlinks from the various INFORMIXDIR locations to the central version. ON-Monitor is within its rights to expect its file to be local, and to expect to be able to rewrite it by removing the old version and creating the new. It does so. That breaks links - hard and symbolic. No, it is not the only way it could be done; it is, however, the way it always has been done. If I had my druthers, then oninit would probably refuse to have anything to do with an onconfig file that was not as secure as it should be. That would mean a variety of things - such as $INFORMIXDIR being properly owned and all directories on the path to it being sufficiently secure (owned by root, bin, or sys and not writable by group - or only limited groups - or others). If symlinks were to be allowed, then the symlink would have to equally secure - which is hard to establish. I'd be happy to keep it that the onconfig file was local to INFORMIXDIR. You can arrange to get a feature request entered to have ON-Monitor be more careful about symlinks and hard links. However, I'm not convinced it is a bug per se (hence feature request), and I'm fairly sure it would not get a very high priority unless the security of the onconfig file is being upgraded - whereupon it would probably be fixed as a side-effect of the upgrade. As to whether ON-Monitor still has a role - the feedback we get every time we've attempted to drop it is "Give me my ON-Monitor back". So it does get used. Personally, I use it for one thing - to get the NETTYPE entries right. When onconfig.std includes a prototype of a NETTYPE entry (so I don't have to remember what the fields mean), then I will have no use for ON-Monitor. It does list the databases - with owner and mode - which is convenient, but the information is also obtainable from sysmaster. So, it has very limited value to me, but the cries from the field indicate that it is still widely used. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/