Re: getting login name in 4GL

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 =============================================================================