Re: getting login name in 4GL

I thought this conversation ended a long time ago? Anyway Using NewEra Apps via the SETNET with Set501.exe seems as if INFORMIX has supplied the userid/password problem accross the NET! Restriction of table access/data/DB is then done via the user id! ------------------------------------------------------------------------- Cheryl Kendricks Internet:cherylk@prod1.jcdc.doleta.gov OR cherylk@gwysmtp.jcdc.doleta.gov DTSI, Inc. Voice: 1-800-598-5008 Fax: 512-393-7296 Database Administrator - DOL Job Corps San Marcos, Texas ------------------------------------------------------------------------ On Thu, 30 May 1996, Tim Schaefer wrote: } David Paulo wrote: } > } > In article <319CD472.5EE8@informix.com>, Kevin Franden <kevinf@informix.com> writes: } > > Cheryl Kendricks wrote: } } [they all wrote a lot of good stuff about whoami and using a c function - see the thread] } } > } > How do you do this if you are client/servering? A trigger/stored proc } > I suppose, but Are you sure that the sqlexec server process is running } > with the users uid and not root or informix? } > } This is always a concern. But to recap the lengthy thread we had on this, } what you ask is precicely why there are two basic issues: } } 1. Getting the accurate id from the host machine } - Security concerns } - tracking } - notification } 2. Getting the accurate id from the data base } - Security concerns } - tracking } - notification } } > Surely } > select user from systables where tabid=1 } > or any other table guaranteed to have a row } > } > is more trustworthy than a script or environment variable? } > If we can't trust the database to get the username right aren't we taking } > paranoia a little too far? } > } Until your system has been compromised by hackers you might think so. Nobody } out there has security problems, right? :-) } } To reiterate, security is one of the main reasons you would care to use a } user id, other than messaging to the user, or the support group maintaining } the application, or logging, or personalizing the app. There are probably } dozens of other reasons each organization can come up with, but in a } multi-user environment the application AND the data base do not live in } a vacuum. As a matter of fact the only way to get Windows95 to honor the } user-login is to use it with Windows NT. What an "Operating System" Windows95 is! } } I recommend you build your apps with a requirement to: } 1. get the host login using one of the posted get_user_id C functions. } 2. get the personalized user stuff from a look-up table. } 3. make all your apps require a parameter for a group, which is also a look-up. } } Item 3 seems tedious, but once you set up your environment and your programs, } it really isn't that big of a deal to implement. If the host is compromised, } then the data base is at risk. If you have the correct host-login, now you } can use the data base, if that user id is valid. This is the achilles heel, } from a security standpoint. } } To increase this difficulty, you take away any and all environment variables } such as INFORMIXDIR, DBPATH, etc., out of theusers' profile. These are added } only at runtime, where they can be tracked. A hacker would have to know how } to use these variables, but if they are not just given to them, the more } secure the data base. } } To make it more difficult to run programs, the required parameters to the } program, such as a group id also slow down the 'penetration' process. If the } source is sufficiently stored out of sight, trying to figure out parameters } can keep the app from being used, and can be tracked by erroring out, since you } put it a 'get_user_id()' C-function, which in turn can be logged, alarms can } sound, the sys admin notified, and hopefully the unauthorized entry ceased. } } A simple group-table-look-up matrix you can try is: } } Col Rows } app app payroll.4ge app func app <--these can be functions too } group x x x } group x x x } ADMIN x x x x x x } group x x x } } to use: payroll.4ge ADMIN } } If someone HAS access, and runs the program without an arg, now it's logged. } } This addresses security only at the group level, hence the need to also use } the user id. You might even expand the above matrix to include a user id } but now the maintenance is a bit more tedious. It is easier to keep } the above table as is with a secondary lookup in the user profile table. } } The user-look-up table can include a series of group1 group2 group3 ... columns. } This way the group table doesn't have to suffer at the hands of the individual } user id, which can come and go. And you can add groups here in addition } to UNIX groups, providing you're using UNIX. If you go C/S, with no UNIX, } then this kind of table might be a good idea. There's always a better } way I'm sure. I do know the above method works, but requires a little } planning, and extra coding. } } Paranoid? Maybe... but I sleep better... } } :-) } } > ---------------------------------------------------------------------- } > David Paulo, InForm Group Ltd.,PO Box 1444, Wellington, New Zealand. } > Ph: +64 4 472 0996 Fax: +64 4 473 2407 Email: david@inform.co.nz } > = What would you do if you knew that you could not fail = } > ---------------------------------------------------------------------- } } -- } \\\\|// } (6 6) } ==============================---o00--(_)--00o---============================ } Tim Schaefer tschaefe@encore.com tschaefe@shadow.net } Encore Computer Corp http://www.shadow.net/~tschaefe } ============================================================================= }