[
https://issues.apache.org/jira/browse/LOG4J2-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16061827#comment-16061827
]
Ralph Goers commented on LOG4J2-1699:
-------------------------------------
For item 2, If there is an error configuring an element standard practice is
that an error or warning is logged using the StatusLogger and a null value is
returned for that element. So in this case it would act like it wasn't
specified, which I think is what you would want along with the logged message.
Ideally, lack of support for this should be caught during configuration, not
while logging an event or during rollover.
For item 3, I would catch the exception, log the issue and return null.
For item 4, every time a rollover occurs DirectWriteRolloverStrategy creates a
new file and starts writing to it. If you want posix attributes specified the
time to do it is when the file is created.
> Configurable Log File Permissions with PosixFilePermission
> ----------------------------------------------------------
>
> Key: LOG4J2-1699
> URL: https://issues.apache.org/jira/browse/LOG4J2-1699
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
> Environment: Linux
> Reporter: Demetrios Dimatos
> Priority: Critical
> Labels: features
> Fix For: 2.9
>
> Attachments: LOG4J2-1699-2.patch, LOG4J2-1699.patch
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> We would like to hear the communities thoughts on being able to configure the
> permissions log files are created with. We don't want to rely on UMASK
> because we have managed services who's process should generate logs with a
> 644 yet deployed applications by users should default to a 640 because the
> logs may contain sensitive information.
> We will make the modification and set this in the properties file. Now we are
> looking to see what the community position would be on accepting such a
> patch, we don't want to be patching our own distribution indefinitely.
> I searched all the JIRAs and was not able to find any matching requirements
> recently. All I could find was something dated in 2006:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=40407
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
