Re: Checking for duplicate subroutine names

[kcott]

G'day Ken,

Unfortunately, that rather sounds like a disaster waiting to happen. What if a user defined a custom subroutine like this:

sub generate_monthly_report { `rm -rf *` }

You may have already considered this sort of thing; however, it raised a red flag in my general direction so I'm just waving it back at you.

[SirBones]

Yes, absolutely understood. We are assuming a group of very local and trustworthy users; their jobs are on the line. ;-)

Cheers,

-Ken

[ww]

Um... not a good assumption.

What happens when one of them becomes disgruntled; is given notice; or the like?

Oops. Bye bye who knows what.

... and what happens, someday in the sweet bye-and-bye when the powers-that-be decide your code creates a business opportunity to be shared with customers?

[ sounds of gnashing of teeth; rending of flesh....]

Please don't do it that way.

[kcott]

My original example certainly suggests blatant maliciousness on the part of some user; however, the most trustworthy of employees, with the best intentions in the world, can write some apparently innocuous code which could have severely adverse side effects.

Consider a user-supplied subroutine which simply reads some data (e.g. get_stock_count()). What happens if that code is called while some system function (e.g. update_stock_count()), which has been running successfully for years with no ill-effects, is in the process of being run? Is the read statement of get_stock_count() executed before or after the write statement of update_stock_count()? What are the implications of this?

[Here's a potential scenario. Supplier (on the phone to User): "Is it a problem if those parts aren't delivered today?". User (after running get_stock_count()): "I've checked the stock count - we've got plenty - next week will be fine.". Production Manager (screaming at Senior Programmer the following day): "The manufacturing plant has ground to a halt. You're responsible for stock count data. User told me he ran code approved by you that reported an adequate supply. Tell me why I shouldn't sack you!"]

My recommendation would be that any user-supplied code goes through the same process of quality control (review, testing, etc.) that you'd expect to apply to your own code.

[SirBones]

I do appreciate the advice and concern, but in this case really no worries. These are isolated test beds (really isolated, they could have no possible contact with any of our production systems; for that matter their network interfaces are limited to the systems they are testing, which themselves have no external connections), with custom Linux images and dedicated hard wired interfaces. Root access is global. We end up rebuilding these things every few weeks (or days) for a number of reasons; if a user sat down and managed an "rm -rf *" I'd simply call him a bloody twerp, take away his Men's Room key, and put a new image on the thing. (I'm lying; we don't have Men's Room keys.)

The security commentary is appreciated and understood but really not a concern in this case. My concern about duplicate subroutine names is entirely based on accidental over-writes, not maliciousness. A malicious or disgruntled user would have lots of better and more effective targets. To vent hostility on the systems I am referring to would be a shamefully unsatisfying exercise for the perpetrator. (And half the time, particularly on a Friday afternoon, I wouldn't mind if they did crash a system or two.)

-Ken