out of locks is security breach

Our database uses row locking. If i would create a table having more rows than there are locks available on the system (easy!) and I would delete these rows: delete from mytable (no transaction, no exclusive lock etc) I would get an error saying somithing about the engine running out of locks and the deleted rows will be rolledback in the table. OK. That's fine, but all other users and processes will experience the same thing and even get error's, thats not fine. I think this is a bug, and if not it most certainly is a security breach: I could criple any engine using row locking! Is there a way to prevent this from happening? --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---

lbaltus@my-dejanews.com wrote: > > Our database uses row locking. > If i would create a table having more rows than there > are locks available on the system (easy!) and > I would delete these rows: > > delete from mytable> > (no transaction, no exclusive lock etc) > I would get an error saying somithing about the engine running > out of locks and the deleted rows will be rolledback in the table. > Yup! > OK. That's fine, but all other users and processes will experience the > same thing and even get error's, thats not fine. > But their transactions would get rolled back, preserving the integrity of the data. > I think this is a bug, and if not it most certainly is a security breach: How could it be a bug? How could it be a security breach? > I could criple any engine using row locking! > . . . until the DBA caught up with you. All relevant information is logged in the online.log. Along the same lines, you could cripple an engine by dropping tables at random. Talk about security breach. Would page locking be any different? I don't think so. It might just take a bit longer. > Is there a way to prevent this from happening? Increase LOCKS, enable coding standards when deleting large amounts of data. Break up large deletes into smaller chunks (that's what we do, for reporting purposes). John Carlson Informix DBA WHSmith USA

In article <37442FDC.99D4B72E@bellsouth.net>, "Carlson@WHSmith" <carlson1@bellsouth.net> wrote: > > How could it be a bug? How could it be a security breach? > > > I could criple any engine using row locking! > > > > . . . until the DBA caught up with you. All relevant information is > logged in the online.log. Along the same lines, you could cripple an > engine by dropping tables at random. Talk about security breach. > > Would page locking be any different? I don't think so. It might just > take a bit longer. > > Is there a way to prevent this from happening? > > Increase LOCKS, enable coding standards when deleting large amounts of > data. Break up large deletes into smaller chunks (that's what we do, > for reporting purposes). > Increasing locks to prevent this from happening would mean increase it to the maximum number of rows in any table (too much) . Dropping tables is covered by the authorization scheme, no breach there. Indeed page locking would not be any different, just less likely to happen. The thing that bothers me most is that *a* user could interfere with the work of another user. I know he could also do this by filling up the database, but that is also not very likely and is partly covered by the log_full.sh script. I would expect on-line to complain to the offending user about not having enough lock, pause processing other users, roll back, free locks and continue with the other users. Is this too much to ask for? (As this is an engine matter, it should be handled by the engine, I know I can catch errors on every 4GL of any other client) Meanfile I learned from Informix that they are working on an option to alocate locks when needed. But that's no good now. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---