nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

inline IPL user question..

System

I have a question that I cant seem to find the answer for..

I have an inline in my DCT (Solaris w/ TS 6.5):

[html]
[/html]

The portal_page_db.ipl reads a properties files (which has the Oracle connection info and PW) and does a DB connection with a simple subsitution for a select Option List..

we had to change the permissions on the properties file to restrict world-read-access since it had the PW for the DB in it.. so now, the inline does not work since it cant read the properties file..

In workflow, we just set the owner of the process, but in a DCT, I dont think we can do that (unless I am wrong)..

so the question is.. does the inline execute as an IWOV system (like iwts or iwui) or the acutal logged-in user themselves?.. I can give access to a couple of system users, but obviously not everyone.. I tried iwui, but that did not work.. and before I keep going back to the sys-admin on this to change permissions over and over.. figured someone might know the answer...

since I can't open up the properties file (that the IPL is using) to world-read-access, are there any ideas on this?

Thanks.

Find more posts tagged with

Comments

nipper

Don't have an answer for you, however you may want to dump your environment variables to a file in /tmp and you may be able to figure it out. Also checking the file ownership will help.

Also, can you setuid the IPL to a certain user that has permission ?

Migrateduser

Don't have an answer for you, however you may want to dump your environment variables to a file in /tmp and you may be able to figure it out. Also checking the file ownership will help.

Also, can you setuid the IPL to a certain user that has permission ?

I was thinking about setuid to the IPL.. but figured if I knew it was just a system user that exectued the file.. then I could just create an admin group and allow that group system-wide to access the file.. which is OK for a couple of process/system UID's.. but thats about it.. and then this way I dont have to have anyone remember to setuid on the IPL's the next time this comes up.. I would think everything in the DCT would execute as an IWOV account.. not a user.. i can have them try iwts as well.. to see if that works, but was just hoping to avoid the back-and-forth..

do the ENV variables show who its run as.. I guess USER= should probably show it..

nipper

do the ENV variables show who its run as.. I guess USER= should probably show it..

That was what I was thinking, after you run it a few times, you can tell.

You will also be certain with the ownership of the output file that is created.

Migrateduser

That was what I was thinking, after you run it a few times, you can tell.

You will also be certain with the ownership of the output file that is created.

well oddly enough when I dump the ENV, there are only 4 variables set (they have values, i just took them out for simplicity)

qx(env > /tmp/jpr1.log);

IW_DCT=
IW_ROLE=
IW_USER=
IW_WORKAREA=

also, what you said makes sense.. the perms on the log file it created was iwui:nobody

though what is odd is, iwui is part of the group mpgroup

the properties files (that is not getting read now) are rw-rw---- mpadmin:mpgroup

yet for some reason.. it cant read the properties file when it executes the ipl..

Migrateduser

also.. i just tried (as a test) to make the properties file RW by only me..

and then made the IPL file owned by me and setuid with chmod 4775

and it still cant read the properties file..

ISCBorisB

If that's of any help, this "nobody" business sounds suspiciously close to the Anonymous NFS User. I kinda recall
seeing 'nobody' and/or 'nfsnobody' as user Names, UID is 65534(max possible) unless your System Admin specified a different one.
If I were you, I would talk to the local Solaris big honhco, see what can possibly be done

Migrateduser

maybe I should be looking at this another way.. maybe I should be telling them to encrypt the PW in the properties file instead.. so its not an issue..

does anyone have any experience/insight with doing that with PERL & DBI Smiley Very Happy

BD and oracle? before I go down that road.. DBI can be difficult enough to get working by itself..

I am trying to not make this a real big issue/task if possible.. which is why I have been looking into the permission side of things first..

nipper

Can you do a newgroup mpgroup in the IPL ?

Migrateduser

Can you do a newgroup mpgroup in the IPL ?

what do you mean do a newgroup in the IPL?

prac.rptdesign

nipper

I am trying to remember my Solaris and there was a command, I thought named newgroup, that would change your primary group to another. If you can change the processes primary group to mpgroup it may work.

ISCBorisB

I am trying to remember my Solaris and there was a command, I thought named newgroup, that would change your primary group to another. If you can change the processes primary group to mpgroup it may work.

Command to change effective GID on the fly is "newgrp". I *beleive* you/your process must be 'root' to be able to run it, if that's the case it won't help

nipper

Command to change effective GID on the fly is "newgrp". I *beleive* you/your process must be 'root' to be able to run it, if that's the case it won't help

Yes newgrp is the command. No you do not need to be root to run it on yourself (or a process you executed). It will allow you to change your primary group from nobody to mpgroup, as long as iwui is part of mpgroup already.

You *may* try to set the group sticky bit on the IPL (and be certain the group is mpgroup)

Migrateduser

Yes newgrp is the command. No you do not need to be root to run it on yourself (or a process you executed). It will allow you to change your primary group from nobody to mpgroup, as long as iwui is part of mpgroup already.

You *may* try to set the group sticky bit on the IPL (and be certain the group is mpgroup)

I had tried the group sticky bit earlier, and that had no effect.. I will give the newgrp a try this evening too.. we will see if that helps.

Adam Stoller

I had tried the group sticky bit earlier, and that had no effect.. I will give the newgrp a try this evening too.. we will see if that helps.

Since you're on Unix - if you want to find out the owner of the process running the inline - dump the values of:

This will verify the UID and GID associated with the process and allow you to determine if it is the logged in user or the server process owner (which I believe is "iwts")

Migrateduser

just to close the loop on this one..

we tried a similar approach to the newgrp.. well just the opposite..

Changing the group on the properties files to nobody (from mpgroup) seems to have done the trick..

thanks for the sounding board..