Re: Permissions on Informix raw devices.

>From: matuscak@rohrer.com (Joe Matuscak) >Subject: Permissions on Informix raw devices. >Date: Tue, 19 Jul 1994 13:36:04 -0400 >X-Informix-List-Id: <news.7672> > >I'm running OnLine 4.1 on a DECsystem 5000. All of my chunks are in raw >partitions. Recently, in the midst of problem with one of our >applications, a support person from the application vendor told us that we >should change the way the permissions on the raw devices are set. I've set >the character special devices to user informix, group informix and 660 >permissions. I pointed out to them that this is what's documented in the >OnLine Administrators guide. They said that they were told by an Informix >engineer that the book was wrong, and that both the character special and >block special devices had to be set to user informix, group informix and >666 permissions. > >So, my question is, is the book right or not? The book is right; the engineer advocating 666 permissions is wrong! To set the permissions to 666 blows away any security on the database -- completely and utterly. Any naive user could accidentally copy a file over the database, and although OnLine would do a surprisingly good job of coping with the problem, but in general, data would be lost. If you don't mind destroying your database, set the permissions to 666 and try: cat /unix /etc/passwd /unix /etc/group /unix > /dev/rdskXYZ where /dev/dsk/XYZ is the raw disk containing your OnLine system. Make sure you have an archive before destroying your real database. That was tongue in cheek -- it is an excellent test of whether you have a decent backup system, but not worth doing if you are in any doubt at all that your archives are secure and current. In fact, I would argue that the block device should be owned by user informix, belong to group informix, and should have 000 permissions. There is no cause to access the block device at all. The raw character) device should be owned by user informix, belong to group informix, and should have 660 permissions. That's the way I set up all my clients' production systems. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> PS: It is actually a good idea to practice recovering your database peridically so that (a) you know what to do if it ever happens in earnest, and (b) you know that your backups are good. Take a routine archive using your normal procedure. If you don't always do level 0 archives, wait until one of the incremental archives is scheduled. Do the incremental archive as normal. Preferably let the system run a little while so you have some logical logs to restore too. It can be make-work activity, but you want to test the whole restore procedure. Then take a special level 0 archive on new media and put it to one side -- this is your final fall back if all else fails. Then destroy your database, roughly along the lines of the cat command cited but doing it as root (you won't be able to do it as an ordinary user because none of your ordinary users belong to group informix and you now know what the correct permissions are). Verify that the database has problems. Use tbcheck if nothing else will do the job. Then go through your standard recovery procedure using the aroutine archives (NOT the special level 0). Ensure that the system is intact. If it is, you have verified your recovery procedures and you can rest easy. If not, you can go to the special level 0 archive and recover from that. It is then imperative that you fix the defective procedures and repeat the exercise, and keep doing so until the recovery can be completed of the routine archives! Always do this before going live with a new OnLine system. And do it periodically with a production system. The peace of mind you get from knowing that your archive system is safe is worth the time it takes.