log4perl file permission troubles. Best practice?

Hi forum,

I'm stuck with log4perl.

I thought to redesign some of the logging that our perl scripts are producing. Heck, I was redesigning some of the scripts itself :-)

Problem: my logfile gets rw-r--r--, and is owned by whatever user started it (typically root or iwui, but could also be any user if I log from impersonated custom menu cgi's, or the workflow instantiator CGI). E.g I now have a module that is called from the .wft file (run as actual user) and from an external task (run as root). Typically, whoever owns the log, locks out anyone else from writing to it.

How do you deal with this?

I noticed that there is a newer version of Log::Log4Perl::Appender::File that allows me to set 'umask'. (the version in vendor/lib is older, and doesn't have that param - but that's fixable). But I was planning to use Log: Smiley Very Happy

ispatch::FileRotate, to have the benefit of rolling logs. Maybe I'll just use the Appender::File with umask 0000 (to get rw-rw-rw-) and rotate the file manually.

thanks for you thoughts!
Fred

Find more posts tagged with

Comments

Frederik

mmm, I think i got a fair solution.

I found that Dispatch::FileRotate is a wrapper on Dispatch::File. The Dispatch::File accepts a "permissions" parameter that it uses to chmod files right after creating them. Plus, Dispatch::FileRotate can just read in that param and ignore it, but still pass it on to the Dispatch::File when it does Dispatch::File->new.

So, all I had to do was add in my configuration file

log4perl.appender.LOGFILE.permissions=438

(438 equals 0666, giving me rw-rw-rw- on the file, so now all process owners can write to my logs. Also, everybody can ruin my logs, but that's a risk I can accept)

phew, for a second there I was afraid I'd have to ditch logging altogether to stay on the project's dev timeline.

-F
/enjoy your weekend

Frederik

The Dispatch::File accepts a "permissions" parameter that it uses to chmod files right after creating them.

The solution that I described above, had one major flaw.

Log: Smiley Very Happy

ispatch::File doesn't just try to chmod a file after it creates it. Probably for efficiency, the code is written to simply open the file (and creating it in the process if it doesn't exist) in the File->new(). Then, it always chmods if requested by the "permissions" parameter. If chmod fails, Log: Smiley Very Happy

ispatch::File *dies* altogether.

Given that in my case, multiple process owners may use log4perl, different users will try to chmod the log file (upon the open for append). And then that process dies, because only file owner (and root) can chmod a file.

So I had to create my own version of File.pm, that does the same as Log: Smiley Very Happy

ispatch::File, but doesn't die if chmod fails. It's a bit of a hack, but it works for now.

Still wondering how others on devnet use log4perl in Teamsite projects, and overcome the 'multiple process owners' problem

--Fred.

chandraiw

Still wondering how others on devnet use log4perl in Teamsite projects, and overcome the 'multiple process owners' problem

--Fred.

how does a seperate log file for each process owner sound?

Adam Stoller

how does a seperate log file for each process owner sound?

You could certainly do that with inline configuration specifications - though I have to say I don't recall running into this problem as long as I ensured that the logfile was chmod'd 666 after its creation (though I haven't deal with the log rotation abilities of Log4Perl yet ... need to play with that soon)

Frederik

hey, I'm happy to see some input :-)

how does a seperate log file for each process owner sound?

You could certainly do that with inline configuration specifications

I guess that would technically solve things, but I don't immediately see how you would do that, except for using a bunch of extra code. Probably it would mean dropping the idea that the configuration of the log4 work can be externally configured via a (single) config file...

My initial instinct says: Since that's part of the beauty of the thing, I wouldn't like to go coding the configuration inline.

Also, I don't much like having a bunch of separate log files, because you then don't see a single timeline (unless you start merging and sorting them also, whenever you look at them; extra work).

You could certainly do that with inline configuration specifications - though I have to say I don't recall running into this problem as long as I ensured that the logfile was chmod'd 666 after its creation (though I haven't deal with the log rotation abilities of Log4Perl yet ... need to play with that soon)

Do you mean *manually* chmodding the log file to 666? Or did you use some standard feature of the log4perl framework for that? As I described, in my experience the Log: Smiley Very Happy

ispatch::File has a parameter for chmodding, but for me it fails in a multi-user environment. As you seem to hint already, manually chmodding isn't an option if you use log rotation offered by log4perl. You probably could do it if you script the use of an external log rotator via cron.

--Fred

Adam Stoller

I guess that would technically solve things, but I don't immediately see how you would do that, except for using a bunch of extra code. Probably it would mean dropping the idea that the configuration of the log4 work can be externally configured via a (single) config file...

Well - you could read-in the config from a file and use a regex to set the filename on a per-user basis and then use the processed string as an in-line config specification...

I guess that would technically solve things, but I don't immediately see how you would do that, except for using a bunch of extra code. Probably it would mean dropping the idea that the configuration of the log4 work can be externally configured via a (single) config file...

My initial instinct says: Since that's part of the beauty of the thing, I wouldn't like to go coding the configuration inline.

Also, I don't much like having a bunch of separate log files, because you then don't see a single timeline (unless you start merging and sorting them also, whenever you look at them; extra work).

I agree.

Do you mean *manually* chmodding the log file to 666? Or did you use some standard feature of the log4perl framework for that? As I described, in my experience the Log:ispatch::File has a parameter for chmodding, but for me it fails in a multi-user environment. As you seem to hint already, manually chmodding isn't an option if you use log rotation offered by log4perl. You probably could do it if you script the use of an external log rotator via cron.

It was manually done, and we did have an external log rotation script.
Another possibility is to make sure that the directory in which the log is located is wide-open and/or that all users are members of a group that you can do a chmod g+s on the directory in which you create the log file - not sure if either of those will alleviate the problem you're seeing though. As I haven't used this module all that long myself I may find myself in a similar situation in the future at some point. Unfortunately, currently, most of my work has been single-user (me) so I haven't had much opportunity to experience what happens when different users run the code I've written :-(
Good luck,

Amlan

The latest version of log4perl provides attributes such as

umask
owner
group

We can set these to set the permissions to the log files. The latest version of log4perl does not ship with interwoven so needs to be installed.

I have a question,
Does the Dispatch::File module give us parameters to set the permissions.

Amlan

Adam Stoller

The latest version of log4perl provides attributes such as

umask
owner
group

We can set these to set the permissions to the log files. The latest version of log4perl does not ship with interwoven so needs to be installed.

I have a question,
Does the Dispatch::File module give us parameters to set the permissions.

Amlan

According to the perldoc for Log: Smiley Very Happy

ispatch::File (here) it would seem to provide for setting the permissions if the file doesn't yet exist the first time it is called.

Frederik

I checked into this again... the Log: Smiley Very Happy

ispatch::File version I'm using from 2005 was already offering to set permission. There is one change in the latest version, that it will only chmod if the actual permissions on the file differ from the wanted permissions.

This fixes the problem I was having, which was that Log: Smiley Very Happy

ispatch::File would attempt to chmod every time the file was opened for writing. If the process user doing the write was different from the owner of the file, the chmod would fail and the subroutine would die. (I worked around that by removing the "die" on chmod failure).