Return-Path: 
 <log4php-dev-return-240-apmail-logging-log4php-dev-archive=logging.apache.org@logging.apache.org>
Delivered-To: apmail-logging-log4php-dev-archive@www.apache.org
Received: (qmail 97335 invoked from network); 1 Aug 2007 17:21:48 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 1 Aug 2007 17:21:48 -0000
Received: (qmail 71569 invoked by uid 500); 1 Aug 2007 17:21:48 -0000
Delivered-To: apmail-logging-log4php-dev-archive@logging.apache.org
Received: (qmail 71528 invoked by uid 500); 1 Aug 2007 17:21:48 -0000
Mailing-List: contact log4php-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:log4php-dev-help@logging.apache.org>
list-unsubscribe: <mailto:log4php-dev-unsubscribe@logging.apache.org>
List-Post: <mailto:log4php-dev@logging.apache.org>
Reply-To: "Log4PHP Dev" <log4php-dev@logging.apache.org>
List-Id: <log4php-dev.logging.apache.org>
Delivered-To: mailing list log4php-dev@logging.apache.org
Received: (qmail 71517 invoked by uid 99); 1 Aug 2007 17:21:48 -0000
Received: from igron-1.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2007 10:21:48 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [216.148.227.152] (HELO rwcrmhc12.comcast.net)
 (216.148.227.152)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2007 17:21:18 +0000
Received: from [192.168.10.101]
 (c-98-198-43-107.hsd1.tx.comcast.net[98.198.43.107])
          by comcast.net (rwcrmhc12) with SMTP
          id <20070801172118m1200hvbife>; Wed, 1 Aug 2007 17:21:18 +0000
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <5D6F9B78-BF7D-4753-84B5-3BA5C2535652@apache.org>
References: <20070723184330.56002a21@sys-251.netcologne.de>
	<46A5ADE7.4080002@php.no> <18096.12767.801665.812346@knoktavian.de.sesa.net>
 <46B0328F.7060502@php.no> <5D6F9B78-BF7D-4753-84B5-3BA5C2535652@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6756F549-5062-4975-BCA8-BAEF11F37C23@apache.org>
Content-Transfer-Encoding: 7bit
From: Curt Arnold <carnold@apache.org>
Subject: Re: Adding umask/chmod to FileAppender?
Date: Wed, 1 Aug 2007 12:21:13 -0500
To: "Log4PHP Dev" <log4php-dev@logging.apache.org>
X-Mailer: Apple Mail (2.752.3)
X-Virus-Checked: Checked by ClamAV on 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.