File permissions on FileAppender

[Curt Arnold <ca...@apache.org>]

There has been a thread on log4php-dev (http://marc.info/?l=log4php- 
dev&m=118520958818276&w=2) that I'd like to get an opinion from the  
log4net developers.  Basically, the user wishes to allow multiple  
user accounts to be able to write to the same log file and they are  
being prevented since the default file permissions set when the first  
user creates the log file prevents the second user from writing to  
it.  The request was to add a umask or chmod configuration option to  
FileAppender.

Aside from the point, that simultaneous access to a common log file  
is unsupported and unreliable in log4j and log4cxx (can't speak for  
log4net and log4php), are there any facilities in log4net for  
controlling the file permissions.  I didn't see any from reviewing  
the log4net code, but I assume that one solution would be to specify  
a <securityContext> for the FileAppender to use a common user.

If you have any comments or advice, either post here or better yet,  
subscribe to the low-volume log4php-dev mailing list (log4php-dev- 
subscribe@logging.apache.org) and post there.

Re: File permissions on FileAppender

[Curt Arnold <ca...@apache.org>]

On Aug 2, 2007, at 1:16 AM, Cliff Burger wrote:

>
> A file is not a good target for multiple users or threads, unless  
> you have some type of service in front of it. If you do, you have a  
> database server.
>
> To be rhetorical: Is building this type of architecture (basically,  
> the IO handling of a DB server) into fileappender in scope of the  
> apache logger?

No, we don't want to attempt to do any file locking or other IO  
synchronization.  You slowly take incremental steps and find that you  
have written a poorly-designed DB server.  The author of the original  
suggestion was concerned with file permissions or modes, not  
synchronization.  He possibly should have been concerned with  
synchronization, but his problem description wasn't explicit whether  
he was expecting his console app and webserver to overlap.

The original suggestion on log4php-dev was to add a chmod or umask  
attribute to allow controlling the file mode or access control list.   
The scenario described was of a console app run  by an interactive  
user account and a web server running under a more limited account  
writing to the same log file.  The author did not state whether he  
anticipated that the operations could be simultaneous or whether the  
console app might have been a web server configuration app that would  
only run when the web server was down.   If the console app was  
intended to be run at the same time the webserver was running, then  
the setup is unreliable and he needs to log to different log files or  
use a different appender that is reliable under those conditions.  We  
do not need to add any new features to support usage that should be  
avoided.

If the console app was a configuration app, then he could get in a  
state where a log file created by the console app could be blocked  
from being opened or appended to by the web server.  log4net appears  
to support that type of scenario with the securityContext element  
where you could say all logging was done using a particular set of  
credentials which would prevent the rights issue.  log4j doesn't  
provide anything along that line.  The proposed enhancement for  
log4php appears to be platform-dependent, but I don't know PHP that  
well.

My thought is that the suggested PHP enhancement is not desirable  
since it appears to be platform specific and encourages unsafe  
behavior.  I don't know enough about the securityContext element in  
log4net to see if it might be a reasonable alternative.

Re: File permissions on FileAppender

[Cliff Burger <cl...@gmail.com>]

A file is not a good target for multiple users or threads, unless you have
some type of service in front of it. If you do, you have a database server.

To be rhetorical: Is building this type of architecture (basically, the IO
handling of a DB server) into fileappender in scope of the apache logger?

Workaround: If you have a highly concurrent, multiple user scenario, just
target something that can safely handle multiple threads and users. E.g. a
database via ADOAppender. I started there, and never looked back. I use the
console / file appenders during unit tests

I understand the overhead of database deployment could be an issue in some
cases - people want to use a file as a target because the file system is
always there. To meet this need, maybe someone has a demo of some really
lightweight / easy configuration that targets something designed for
multiple users (doesn't require a database server?)


On 8/1/07, Curt Arnold <ca...@apache.org> wrote:
>
> There has been a thread on log4php-dev (http://marc.info/?l=log4php-
> dev&m=118520958818276&w=2) that I'd like to get an opinion from the
> log4net developers.  Basically, the user wishes to allow multiple
> user accounts to be able to write to the same log file and they are
> being prevented since the default file permissions set when the first
> user creates the log file prevents the second user from writing to
> it.  The request was to add a umask or chmod configuration option to
> FileAppender.
>
> Aside from the point, that simultaneous access to a common log file
> is unsupported and unreliable in log4j and log4cxx (can't speak for
> log4net and log4php), are there any facilities in log4net for
> controlling the file permissions.  I didn't see any from reviewing
> the log4net code, but I assume that one solution would be to specify
> a <securityContext> for the FileAppender to use a common user.
>
> If you have any comments or advice, either post here or better yet,
> subscribe to the low-volume log4php-dev mailing list (log4php-dev-
> subscribe@logging.apache.org) and post there.
>