jfd@octel.UUCP (John F. Detke) (04/25/91)
Hello, We are trying to setup an Informix DB on a SPARCstation. Has anyone had any better luck with the Informix non-support line? Waiting 20 minutes on hold to talk to a decidedly non-UNIX support person is frustrating at best. Anyhow, our current problem is: Informix wants to chmod and chgrp informix /dev/rsd0d in order to use raw partitions. Why the heck do they have set-uid root programs then? The DBA wants the speed improvements, but I am reluctant to open up /dev like this. Am I being too paranoid? It doesn't help that the first instal the DBA did this (Having temporary root access) and promptly wrote over the disk label. How do other sysadmins handle raw partition access? Also: if Informix is listening: How the hell do you justify pricing Informix on a 4/490 $20,000 (or more, depending on who we talk to) more than on a SPARCstation II? I KNOW the code is the same! The SPARC II is arguably faster than a 4/490, but of course the 4/490 (should) handle heavy I/O better (but at $20,000 more I can buy another Sparc II with 1GB disk). Oh, and please replace the person writing your install scripts. I am getting sick of re-writting them properly. Can anyone recommend a DB that handles bin files that is saner than Informix? I would love to buy a reasonable & supported product. Please use email, I will summarize if there is interest. Thanks, jfd -- John F. Detke Octel Communications Corp 890 Tasman Drive M/S 05-04 Milpitas CA 95035 jfd@octel.com
dlw@odi.com (Dan Weinreb) (04/26/91)
In article <461@octelb.octel.UUCP> jfd@octel.UUCP (John F. Detke) writes:
Informix wants to chmod and chgrp informix /dev/rsd0d
in order to use raw partitions. Why the heck do they have set-uid root programs
then? The DBA wants the speed improvements, but I am reluctant to open up /dev
like this. Am I being too paranoid?
I don't think I understand. Informix needs for their Unix process to
be able to access /dev/rsd0d. They are saying that you should chmod
it to something, and chown it to "informix", in order to grant access
to their process. It seems that you are saying that you don't like
the idea of doing this, because it would "open up /dev", implying that
this would create a possible security problem. Instead you are
counter-proposing that they make their program a "setuid root"
program.
If I were paranoid, I might be more worried about letter their process
run as "root" than about setting the access on /dev/rsd0d as they
recommend. Setting the access will only let their process access that
device, and not others; making their program run as "root" will let
their process access any device whatsoever. Why would it be more secure
for them to run as "root"?eric@cinnet.com (Eric Bardes) (04/27/91)
From article <461@octelb.octel.UUCP>, by jfd@octel.UUCP (John F. Detke): > How do other sysadmins handle raw partition access? My company sets up raw devices under the directory $INFORMIXDIR/dev. We generally name the devices using the space name. That is: cwr-wr--- 1 informix informix 12 0x00030a 04:00:13 rootdbs.1 cwr-wr--- 1 informix informix 12 0x00040a 04:00:13 rootdbs.2 cwr-wr--- 1 informix informix 12 0x000407 04:00:13 dbs1.1 cwr-wr--- 1 informix informix 12 0x000307 04:00:13 dbs1.1 This keeps Informix out of our /dev directory. Also if I loose a disk for whatever reason. It is easy to install a new drive into the old filename. > Informix wants to chmod and chgrp informix /dev/rsd0d > in order to use raw partitions. Why the heck do they have set-uid root > programs then? Some processes, such at sqlturbo run setuid to informix. The real uid remains at joe_user. Sqlturbo needs to be able to read and write these raw partitions. Hope I was able to help. ----------------------------------------------------------------------------- Eric E. Bardes 7651 Cornell Rd Cincinnati, OH 45242-3015 uucp: cinnet!eric -----------------------------------------------------------------------------
proberts@disk.uucp (Phil Roberts) (04/27/91)
jfd@octel.UUCP (John F. Detke) writes: >Hello, >We are trying to setup an Informix DB on a SPARCstation. Has anyone had any >better luck with the Informix non-support line? Waiting 20 minutes on hold to >talk to a decidedly non-UNIX support person is frustrating at best. Anyhow, >our current problem is: Informix wants to chmod and chgrp informix /dev/rsd0d >in order to use raw partitions. Why the heck do they have set-uid root programs >then? The DBA wants the speed improvements, but I am reluctant to open up /dev >like this. Am I being too paranoid? It doesn't help that the first instal >the DBA did this (Having temporary root access) and promptly wrote over the >disk label. How do other sysadmins handle raw partition access? I have been using Informix products since '86, and have never received anything less than excellent support and service from them. Informix, unlike many other large companies I have dealt with, gets all A's on my report card. Sounds like you need a new DBA who knows what he's doing. >Also: if Informix is listening: How the hell do you justify pricing Informix >on a 4/490 $20,000 (or more, depending on who we talk to) more than on a >SPARCstation II? I KNOW the code is the same! The SPARC II is arguably faster >than a 4/490, but of course the 4/490 (should) handle heavy I/O better (but >at $20,000 more I can buy another Sparc II with 1GB disk). >Oh, and please replace the person writing your install scripts. I am getting >sick of re-writting them properly. Sounds like you had a grudge against Informix before you ever had any dealings with their support staff. You were probably forced to use their product by a manager who knew a good product when he/she saw it. It's tough when we have to learn a new product, isn't it. (I don't remember how to draw the smiley with it's tongue sticking out, but if I did I would put it here.) >Can anyone recommend a DB that handles bin files that is saner than Informix? >I would love to buy a reasonable & supported product. Try Informix 4GL or Informix SQL. :-) >Please use email, I will summarize if there is interest. >Thanks, >jfd >-- >John F. Detke >Octel Communications Corp >890 Tasman Drive >M/S 05-04 >Milpitas CA 95035 >jfd@octel.com
aland@informix.com (Colonel Panic) (04/30/91)
In article <1991Apr26.150939.2069@odi.com> dlw@odi.com writes: >In article <461@octelb.octel.UUCP> jfd@octel.UUCP (John F. Detke) writes: > Informix wants to chmod and chgrp informix /dev/rsd0d > in order to use raw partitions. Why the heck do they have set-uid root programs > then? The DBA wants the speed improvements, but I am reluctant to open up /dev > like this. Am I being too paranoid? > >I don't think I understand. Informix needs for their Unix process to >be able to access /dev/rsd0d. They are saying that you should chmod >it to something, and chown it to "informix", in order to grant access >to their process. It seems that you are saying that you don't like >the idea of doing this, because it would "open up /dev", implying that >this would create a possible security problem. Instead you are >counter-proposing that they make their program a "setuid root" >program. The engines are already setuid for the following purposes: 1) boost ulimit up to an arbitrarily high value 2) set groupid to informix After doing so, real and effective uids are set back to those of the invoking user (hence the need to have the devices read/writeable by group informix). >If I were paranoid, I might be more worried about letter their process >run as "root" than about setting the access on /dev/rsd0d as they >recommend. Setting the access will only let their process access that >device, and not others; making their program run as "root" will let >their process access any device whatsoever. Why would it be more secure >for them to run as "root"? Perhaps Mr. Detke is concerned that this would allow an Informix process to run rampant over his devices. As long as /dev is read/search only for non-root uids, I don't see a problem. Also, this is a good time to bring this up. As a safeguard against media failure, it's always best to use a logical pathname rather than the actual device path. We recommend assigning logical names to each slice to be used by OnLine by building hard links. In the above case, if the following is done: cd /dev ln rsd0d online_1 chown informix online_1 chgrp informix online_1 chmod 660 online_1 and /dev/online_1 is used in the OnLine configuration screen (and tbconfig file), it makes recovery easier. If Disk 0 were to fail, you could reassign another slice of equal or greater size and restore to the new slice: cd /dev rm online_1 ln rsd2d online_1 chown informix online_1 chgrp informix online_1 chmod 660 online_1 Then, just reinitialize, restore, and you don't have to rely on that particular device being available. -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland "The biggest problem with baseball today is the money being thrown around. The players aren't in the sport for the joy of the game anymore, they're in it for the money. Greed is ruining baseball." - Rogers Hornsby (when Cincinatti Reds manager), 1953
ben@oy.sybase.com (benjamin e. von ullrich) (05/01/91)
In article <461@octelb.octel.UUCP> jfd@octel.UUCP (John F. Detke) writes: >We are trying to setup an Informix DB on a SPARCstation. Has anyone had any >better luck with the Informix non-support line? Waiting 20 minutes on hold to >talk to a decidedly non-UNIX support person is frustrating at best. Anyhow, >our current problem is: Informix wants to chmod and chgrp informix /dev/rsd0d >in order to use raw partitions. Why the heck do they have set-uid root programs >then? The DBA wants the speed improvements, but I am reluctant to open up /dev >like this. Why does giving access to one partition ``open up /dev??'' It's not like they have write permission to the directory. As long as the partition doesn't have anything to do with other operations, (such as being at cyl 0 or overlapping another partition), there is no more risk in granting a user access to a partiton of the disk than letting her create files in a filesystem. The other point about running suid root has already been aptly made. >Also: if Informix is listening: How the hell do you justify pricing Informix >on a 4/490 $20,000 (or more, depending on who we talk to) more than on a >SPARCstation II? I KNOW the code is the same! The SPARC II is arguably faster >than a 4/490, but of course the 4/490 (should) handle heavy I/O better (but >at $20,000 more I can buy another Sparc II with 1GB disk). Sun naturally positions its departmental servers (4/400 series) in a price range far above the workstation-class (SPARCstation-2) series. The SPARCstation-2 may have a faster processor, but a faster processor doth not a fast, all-purpose computer make. In this age of RISC, the majority of newer workstations have much faster processors than their larger predecessors. Servers are more expensive because they have much more capacity, bus and i/o bandwidth for large data processing needs. They are priced accordingly: big systems == big bucks. The software vendors do the same thing: they ship the same binary for both systems, but charge drastically different rates. This is because the price range for the two systems is different, and the software can naturally follow in sync. Once you decide to buy a big box, you decide to pay big bux for everything. The argument can be made that you get more utility out of software running on a big box, and might get that same utility on a SPARC 2, but pricing normally adheres to different principles. Believe it or not, no one charges the same as it costs to make software when they sell it! Golly! As I usually say to those who surmise they can do something cheaper and more cleverly than others: go do it if it's such a good idea, and spare us the whines. ..ben ------ benjamin e. von ullrich only i do the talking here -- not my employer. ben@sybase.com {pyramid,pacbell,sun,lll-tis}!sybase!ben "why waste time learning when ignorance is instantaneous?" -- hobbes on calvin