Re: Security / ODBC Drivers

You might be able to control this by revoking add/update/remove privileges from public, then add those privileges to a special user, and do a setuid on your 4gl startup menu program to cause your 4GL users to become the one user with those privileges. David Killough wrote: > > We have set up every user on our system to be able to update, delete, > and insert into any table in our database. Our 4GL programs have been > the only interface our users have had with the database, so we have been > able to control what is changed. Now we are trying to give users > reporting capabilties through ODBC drivers and have not been able to > restict the access to read-only. They link the tables into MS-Access > and can change anything they want to!! I can't change the database > permissions because the 4GL programs depend on the user and the current > permissions. I need to find out if there's a way to keep the ODBC > driver access read-only while keeping the 4GL access read-write. > > Thanks in advance for any help on this issue. > > Dave Killough > > > -- Colin McGrath cmm@trac3000.ueci.com Raytheon Constructors Inc. (215) 422-4144 Philadelphia, PA, USA Any opinions I state are my own and not necessarily those of my employer

Colin M McGrath wrote: > You might be able to control this by revoking add/update/remove privileges > from public, then add those privileges to a special user, and do a setuid > on your 4gl startup menu program to cause your 4GL users to become the > one user with those privileges. But beware that Informix normally takes the real UID rather than the effective UID (for hysterical raisins, as usual). This makes it necessary to use a SUID root program to do the UID-setting. That opens up a whole bag of different security issues. > David Killough wrote: > > We have set up every user on our system to be able to update, delete, > > and insert into any table in our database. Our 4GL programs have been > > the only interface our users have had with the database, so we have been > > able to control what is changed. Now we are trying to give users > > reporting capabilties through ODBC drivers and have not been able to > > restict the access to read-only. They link the tables into MS-Access > > and can change anything they want to!! I can't change the database > > permissions because the 4GL programs depend on the user and the current > > permissions. I need to find out if there's a way to keep the ODBC > > driver access read-only while keeping the 4GL access read-write. This a perennial problem. You want to be able to identify both the user and the program which is accessing the database, and to grant the user certain privileges when using certain applications, and you want to grant the same user different privileges when using other programs. That level of granularity is not supported. Nor is it easy to see how to add it, desirable though it undoubtedly is. You might be best off writing the modify (INSERT, DELETE, UPDATE) code in DBA-privileged stored procedures, and only allowing the 4GL code to use those (and hence deny users the option of modifying the tables). However, this is still security through obscurity. Ditto for using ROLES. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>