Re: httpd(8) log files are world and daemon-readable

Piotr,

You are the one who explicitly brought up GDPR compliance to justify this patch.  You don’t get to invoke international privacy regulations as a hammer and then claim the discussion isn’t about that when your threat model is dismantled.

Your definition of “State of the Art” under data protection frameworks is legally incorrect.  “State of the Art” refers strictly to the current baseline of global technological capability, not “whatever isolation mechanism is currently popular.”  While the GDPR absolutely allows low-risk operations to use proportional measures like standard file permissions, it does not redefine technical baselines.

The wheel group is absolutely not a better choice for log analysis.  That group is dedicated solely for administrators.  Giving any local user wheel access is the same as handing them the keys to the kingdom.

Nginx and Apache httpd both create log files with permission 644 and in the case of Apache httpd, this can be configured to 640.  These industry standard daemons expect the administrator to use umasks to further tighten permissions.  Most distros of Linux lock permissions to 640 and use group adm or another dedicated group.  No major distro or OS sets the permissions to root-only.

As a system default, root-only permissions is a bad choice for web logs and is considered an anti-pattern.

-Brian

> On Aug 28, 2026, at 10:29 AM, Piotr Durlej <[email protected]> wrote:
> On Fri, Aug 28, 2026 at 09:42:45AM -0400, Brian Brombacher wrote:
>> If they are trusted users, why are you worried about them accessing your web logs?  Obviously they are authorized to be logged into your web server, so they must be authorized to view web logs.  I assumed you had untrusted local users since you were so concerned about file permissions.
>> 
>> GDPR requires “State of the Art” security and isolation techniques, not “whatever my OS provides.”  For over the past decade, hypervisor-enforced isolation has been the industry standard for separating untrusted workloads.
>> 
>> If you did have untrusted local users logging into your web server, that would absolutely fall under “willful and negligent” violation the moment you have a security incident or data breach and someone comes to investigate.  There have been huge fines given out for this exact design.  The entire legacy web hosting industry is in legal hot water right now until they fully containerize/virtualize their individual tenants.
>> 
>> Maybe a better solution is group-readable web logs for a dedicated group, like _logread or something.  That way the default system caters to you and to everyone else who wants to run log analysis programs as non-root users.
>> 
>> Making users figure out what knobs to turn in order to make their own group-readable logs will just result in more users running fragile log analysis scripts as root instead.
>> 
>> -Brian
> 
> Brian,
> 
> A few points need clarification, because the original discussion was about file permissions and least privilege defaults, not about multitenant hosting or GDPR issues.
> 
> Having shell accounts for trusted users does not imply that all of those users are authorized to read every category of data on the system. Being trusted enough to log in does not automatically grant access to HTTP logs, which may contain IP addresses, user agents, session identifiers, or other data that some deployments treat as sensitive. Least privilege still applies, even among trusted users.
> 
> GDPR also does not mandate hypervisors, containers, or any specific isolation technology. The term "state of the art" refers to appropriate measures relative to the actual risk in a given context, not to whatever isolation mechanism is currently popular in the hosting industry. For small, low risk deployments, correct Unix file permissions are entirely acceptable. Regulators do not require virtualization as a condition for running a multiuser Unix system.
> 
> The presence of multiple local users is not itself a GDPR problem. A problem arises only if users can access data they are not supposed to access. If log files are readable only by root or by a dedicated group, and permissions are set correctly, the requirement is satisfied.
> 
> Your suggestion of a dedicated group such as _logread is reasonable for setups where non-root log analysis is desired (probably the wheel group may be a better choice).
> 
> The original concern was simply about default permissions and avoiding unnecessary exposure of log data. OpenBSD already provides the mechanisms needed for that, and they work well when configured according to the usual least privilege principles.
> 
> Kind regards,
> Piotr Durlej