On Aug 1, 2007, at 11:37 AM, Curt Arnold wrote:
On Aug 1, 2007, at 2:13 AM, Knut Urdalen wrote:
Michael Schmitz wrote:
I disussed almost the same issue with the log4perl guys as the
problem
Christian described is actually a major problem in our project. I
think it would be a great idea to permit specification of the file
mode via the configuration.
Ok, I have nothing against adding Christian's patch :) Just
interesting to hear Curt's view on this issue since log4j does not
have this feature.
Curt: Do you have anything to add?
Knut
I'm subscribed to the list, so you don't need to cc me.
I think the lack of the feature in log4j is due to the lack of a
portable API for setting file permissions in Java. log4net may
have more access to OS-level features and might have insight here.
I'll ask them for comments. I browsed the log4net code and didn't
see any obvious hook for setting file permissions. The could nest
a <securityContext> element as a child of FileAppender and maybe
that participates. I don't think log4cxx has anything.
I've posted a query on the log4net-dev mailing list and suggested
they respond here, but will let you know if a conversation erupts there.
While trying to explain the situation, it struck me that the
motivation in the original posting was problematic. It is a common
mistake for log4j users to either intentionally or unintentionally
have multiple JVM's attempt to write to the same log file. log4j
does not provides (and as far as I know, could not provide without OS
specific code) any file-locking on the log file and simultaneous use
of the same log file is unsupported, unreliable and but usually
undetected. The original poster had mentioned that he wanted to have
a console app and a web server write to the same log file. With
log4j, if the permissions problem was addressed, you would still have
the problem that running the console app while the webserver was
running could potentially corrupt the log file. Adding support for
chmod/umask might encourage having multiple users write to the same
log file which without some external synchronization could result in
a corrupt log file.
log4net does appear to provide the means to specify a securityContext
for a log file which should allow you to specify that logging should
occur only under one user account. I don't have any experience with
this, but if you knew that you had no danger of simultaneous access
to the log file (for example, your console app checked if the web
server was running first), you could specify that all logging should
be done as the webserver user. I don't know if that would prompt you
for the credentials.
