You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4php-dev@logging.apache.org by Michael Schmitz <Mi...@tietoenator.com> on 2007/08/01 09:10:23 UTC
Re: Adding umask/chmod to FileAppender?
Hello all,
>>>>> "Knut" == Knut Urdalen <kn...@php.no> writes:
Knut> Christian Hammers wrote:
>> Would adding a file_mode=0664 flag to the FileAppender be a
>> proper way to solve this problem?
Knut> Have you tried running the console scripts as the same user
Knut> as the webserver?
Knut> Example:
Knut> $ sudo -u www-data php script.php
Knut> log4j doesn't seem to have this feature so I think this is
Knut> the right thing to do.
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.
Regards,
Michael.
Re: Adding umask/chmod to FileAppender?
Posted by Christian Hammers <ch...@lathspell.de>.
Hello
On 2007-08-01 Curt Arnold wrote:
> 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.
That's a good point, I am indeed in danger of this situation with my
several programs configured to write into the same logfile.
Would it be good to add file locking to the log4php wishlist? I think
it's common to have a big application that consists of several small
console programs, scripts and web-interfaces that all want to write
into the same logfile to not have 5 different logfiles to look into.
bye,
-christian- (who whishes a mixture of log4X and syslog :))
Re: Adding umask/chmod to FileAppender?
Posted by Curt Arnold <ca...@apache.org>.
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.
Re: Adding umask/chmod to FileAppender?
Posted by Curt Arnold <ca...@apache.org>.
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.
Re: Adding umask/chmod to FileAppender?
Posted by Knut Urdalen <kn...@php.no>.
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
Re: Adding umask/chmod to FileAppender?
Posted by Michael Schmitz <Mi...@tietoenator.com>.
>>>>> "Schmitz" == Michael Schmitz <Mi...@tietoenator.com> writes:
>>>>> "Curt" == Curt Arnold <ca...@apache.org> writes:
Curt> On Aug 1, 2007, at 2:10 AM, 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.
Curt> I asked for comments on log4net-dev
Curt> (http://marc.info/?l=log4net- dev&m=118598739032116&w=2) and
Curt> didn't get much insight beyond don't have multiple processes
Curt> hit the same log file (which is a good and true statement).
Curt> log4net has the idea of a nested securityContext where you
Curt> can specify that logging would be done as a particular user
Curt> (which would be one way around the file permissions issue),
Curt> but I have no direct experience with it.
Curt> Is there an archive of your discussion with log4perl?
Schmitz> No, I don't think so. My dicussion regarding an
Schmitz> initialization issue are in the archive, but this one
Schmitz> not.
<snip>
I just looked at the manual of the file appender in log4perl and saw,
that one can specify umask, owner and group (plus some more options)
for a appender.
Re: Adding umask/chmod to FileAppender?
Posted by Michael Schmitz <Mi...@tietoenator.com>.
>>>>> "Curt" == Curt Arnold <ca...@apache.org> writes:
Curt> On Aug 1, 2007, at 2:10 AM, 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.
Curt> I asked for comments on log4net-dev
Curt> (http://marc.info/?l=log4net- dev&m=118598739032116&w=2) and
Curt> didn't get much insight beyond don't have multiple processes
Curt> hit the same log file (which is a good and true statement).
Curt> log4net has the idea of a nested securityContext where you
Curt> can specify that logging would be done as a particular user
Curt> (which would be one way around the file permissions issue),
Curt> but I have no direct experience with it.
Curt> Is there an archive of your discussion with log4perl?
No, I don't think so. My dicussion regarding an initialization issue
are in the archive, but this one not.
Curt> Since umask and chmod both seem to be provided as standard
Curt> PHP library functions, then it seems that PHP is responsible
Curt> for emulating or stubbing them on Windows or other platforms
Curt> with different file permission models.
Curt> I would suggest that if the user does not specify a umask or
Curt> chmod value, then umask or chmod not be called. Looking at
Curt> the original patch, it seemed like it did not have a concept
Curt> of an unspecified umask. Since both umask and chmod have
Curt> warnings, I'd suggest implementing them both and the user is
Curt> responsible for making the right choice (and if they
Curt> specified neither than neither function is called).
This sounds like a good suggestion to me.
Re: Adding umask/chmod to FileAppender?
Posted by Curt Arnold <ca...@apache.org>.
On Aug 1, 2007, at 2:10 AM, 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.
>
I asked for comments on log4net-dev (http://marc.info/?l=log4net-
dev&m=118598739032116&w=2) and didn't get much insight beyond don't
have multiple processes hit the same log file (which is a good and
true statement). log4net has the idea of a nested securityContext
where you can specify that logging would be done as a particular user
(which would be one way around the file permissions issue), but I
have no direct experience with it.
Is there an archive of your discussion with log4perl?
Since umask and chmod both seem to be provided as standard PHP
library functions, then it seems that PHP is responsible for
emulating or stubbing them on Windows or other platforms with
different file permission models.
I would suggest that if the user does not specify a umask or chmod
value, then umask or chmod not be called. Looking at the original
patch, it seemed like it did not have a concept of an unspecified
umask. Since both umask and chmod have warnings, I'd suggest
implementing them both and the user is responsible for making the
right choice (and if they specified neither than neither function is
called).