| Author |
Message
|
| jharringa |
 Posted: Tue Aug 28, 2007 8:17 am Post subject: broker jvm and log4j permissions on files (AIX) |
 |
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
I've been working on this for a few days with a few other people and we're stumped. We are running the broker on an AIX box and one of my flows takes in an XML message off of an MQ queue and writes out to log files using log4j. Everything works alright except the permissions on the files are -rw-rw----. The problem with this is that we need to be able to read the files from another JVM (or another user outside of the broker's group). I have searched around and everyone seems to say that the umask controls the file's permissions. However, the umask is set as 022. Is there something that the broker or the JVM is doing to keep the file permissions down to 640 or something like that?
Another oddity to put into the mix is that I'm redirecting syserr and sysout to the same directory so that we can easily see those files if log4j outputs any warnings or errors and those files have permissions of -rw-r--r--. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Aug 28, 2007 8:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you restart broker after changing umask?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jharringa |
| Posted: Tue Aug 28, 2007 9:21 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
| we have just done a restart of the config manager and the broker to be sure of that and we get the same results. In fact all files created now have 660 (-rw-rw----) permissions. That includes the sysout and syserr files. Is there a way to specify the default permissions other than limiting permissions with umask? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 9:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
umask *is* "default" permissions. But it's a shell level thing, so it doesn't take effect until you change it in the shell running your code (i.e., restarting broker).
You can put a .sh script in <workpath>/common/profiles and mqsiprofile will source them for you. This would allow you to set umask in a place you know will be in effect when you start broker.
You can also look at sticky permissions on the folder holding your log files.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Tue Aug 28, 2007 9:52 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
I am working with jharringa on this issue as the unix administrator. The umask is set to 022 which is default and should create files with world read permissions by default. This log4j utility is creating files with 660 permissions and our log viewer cannot read them.
We are looking at setting sticky bits on the directory to always make every file in that directory world readable by anyone no matter what. I have not found a method to do this. Sticky bits are not designed to do what we are trying to do here. I've asked quite a few admins here and we can't come up with a valid solution here. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 10:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's a question of whether the umask is set in the shell that is running the Broker JVM (which is contained within the DataFlowEngine processes for each Execution Group).
Or it should be.
I guess my memory on sticky permissions is not what I thought it was.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Tue Aug 28, 2007 11:45 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| I've set umask to 022 in /etc/security/users (for each user), I've set it to call umask 022 in each users .profile. I don't know of anywhere else to set umask, but the files are getting written with 007 umask by the broker userID. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 11:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's the broker userid that needs the umask.
And it needs to be set in the shell that is running the broker.
The easiest way to do this is to create a very simple shell script, that just sets the umask, and put that in what should be /var/mqsi/common/profiles
Then the mqsiprofile will source that script, as part of it's execution.
So you can log into the broker service user or broker admin user (which will source mqsiprofile) and then mqsistop and mqsistart the broker, and the umask should be in effect.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Tue Aug 28, 2007 12:31 pm Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| I thought this may be the answer, but it wasn't. The log files are still having the 660 permissions even though I called umask 022 in /var/mqsi/common/profiles/setumask.sh |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 12:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What are the permissions on the directory that the files are being written into?
You might need to open a PMR. 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Tue Aug 28, 2007 12:52 pm Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| This has driven me nuts for 3 days now. The permissions on the directory are 775. I'm pretty sure IBM won't help. We're using log4j to write these logs, there is a NFS mount from this box to another websphere JVM application server for log viewing. I think I'll explain all of this to IBM and they will just laugh. Basically I just need to have world read permissions on the logs that are being written into this directory. I'm pretty close to writing a cron job to chmod -R 775 /thislogdirectory every minute. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 1:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd risk getting laughed at, myself.
NigelG might not like me for saying that, but oh well.
You shouldn't need to change the permissions more than once, after the file is created.
Are you looking at the permissions as set on the broker machine, or as set on the NFS mount?
These may be entirely different things...
And the permissions you set on the underlying mount point may override or otherwise interfere with the permissions on the mounted file system...
And you could try creating a symlink in the NFS mount, with different permissions than the mount, as well, and have everyone read from that...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Wed Aug 29, 2007 5:31 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
This is a log viewing method we have been using successfully for years. The only thing it needs is world read permissions on the logs that are created on the broker machine. For the most part, the remote WAS server should be invisible to this situation after the remote mounts are set up.
I have thoroughly looked at the permissions and remote mount point permissions and this isn't the problem. I say that partially because if there are 3 logs created in my directory, two of them will have rw-rw---- and I chmod one other to have rw-rw-r---. The third file with world read is readable through the log viewer. This is why I believe it's a simple issue of getting that read bit set on these files.
Since this problem didn't crop up until log4j came into the picture, I think this is a log4j issue now and they do not have a way to chmod any files after they are created (according to what I have been reading). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 29, 2007 5:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I did some quick scanning of the log4j documentation as well, and came to the same conclusion that there's no ability in it to change the permissions of the files that it writes out.
It's not clear that log4j should be ignoring umask, though.
I guess it may be helpful to have the application team try using a JavaCompute node to write a test file into the same directory, and see if the umask applies or not.
If the umask doesn't apply, and the permissions end up the same as the log4j files... then it is likely some kind of issue with the Broker JVM.
But it's certainly easier by far to write a cronjob to reset the permissions on these files periodically.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Wed Aug 29, 2007 1:13 pm Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
Just a quick update in case this comes in useful for someone in the future. We are using java code in a compute node to wrote stderr.out to this same directory. Using the IBM java, and taking out log4j, we still have the bad permissions. Since I found this out, I opened a PMR up with IBM and am pursuing it through them.
Thanks for your input jeff you have been very helpful. |
|
| Back to top |
|
|
|
|
