Re: 4gl and sql access
Posted in 1991
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
Under SysVR2.2, only root or the uid itself can do the setuid! This means the program has to run suid root or suid dbm. Dbm is more secure. In either case, once you are running as dbm, it is impossible, as far as we can tell, to switch back to the real user before doing a shell escape. We are open to a way around this. In the meantime, we hardwire in the ids of the users we will permit to do shell escapes. The shell escape code looks like this. Thanks for the info. Yours was the only one that stood a chance of working. Unfortunately, it would appear that the "setuid(dbm)" only works if the program is setuid to root and not to the dbm. This application cannot be setuid root since the machine is run for us and we don't have root access. sigh sigh. You are absolutely correct. I just tested it. We had always run it suid root. I changed it because it seemed to work. Unfortunately, none of the people with restricted access had tried it since the change or you can bet I would have heard about it real quick! I had thought running suid dbm would work, but once 4gl does a suid realuser, my setid call fails because only root can change to another id. I put it back suid root. I am sorry this does not help you, but it is a solution where you can run suid root and it does seem secure.