Re: svlogd and umask settings

[Christian Holtje <list.supervision@docwhat.gerf.org>]

Vincent Danen wrote:
> * Gerrit Pape <pape@smarden.org> [2006-09-15 14:47:44 +0000]:
> 
>>>> I have an issue with svlogd where I need it to write files with 0640
>>>> perms, but it wants to write with 0644 perms.  I tried to toss a umask
>>>> call in my runscript:
>>>> This doesn't seem to make a difference to svlogd.  Looking in the
>>>> manpage, I didn't see anything about changing the permissions of files
>>>> it creates.  But even with the above I get:
>>>>
>>>> [root@ares apparmor.d]# ls -l /var/log/system/audit/
>>>> total 0
>>>> -rw-r--r--  1 root root 0 Aug 30 16:17 current
>>>> -rw-------  1 root root 0 Aug 30 16:17 lock
>>>>
>>>> What am I missing or do I have to change something in svlogd itself?
>>>> Since Annvix is now using socklog by default, I need to make sure logs
>>>> are 0640.  The directory permissions are correct, but the log file
>>>> permissions are not.
>>> Ok, I see the problem.  I see all the fchmod() calls in svlogd.c that
>>> are writing files as mode 0744 or 0644.  What would be nice to see is if
>>> svlogd could be configured to accept as a config option perms for files
>>> or if it respected umask settings.  As it stands right now, I'm going to
>>> have to patch svlogd.c to make it write files mode 0740 or 0640.
>> Yes, this is compiled in.
>>
>>> In conjunction with stuff like socklog, this is pretty important.  You
>>> never see stuff like /var/log/messages or /var/log/auth.log with such
>>> insecure permissions so it would be good if something that socklog
>>> depended on could likewise write more secure log files.
>> Isn't it enough to set restrictive permissions on the directory?  svlogd
>> won't touch these settings.
> 
> I could, yes, but it just seems wrong to me.  =)  I do already have
> restrictive settings on the parent directories, and having looked at it,
> it does look well enough (ie. keeps the snoopers out).
> 
> I'm trying to have everything write with the correct perms, however, and
> not rely on other things because while svlogd may not change the perms
> on the parent directory, a dumb admin might and I'm aiming to protect
> dumb admins from themselves.

I would argue that more important than the idea of protecting a
sys-admin is the principal of least surprise.  The sys-admin user
here tried to change the mask of the log files by changing the umask.

This implies that a user expects umask to be effective.  On the flip
side, we don't want to be _accidentally_ creating 777 files.

I would suggest putting an entry in the log, upon svlog startup,
that complains about possibly unsafe permissions.  I wouldn't be
adverse to svlog preventing umask from being less than 002, at least
not without specifying a flag.

Example Log message:
  **** SVLOG has determined that your umask (000) would make the
file permissions unsafe.  I'm going to override your umask to 022.
If you meant for umask to be this, then please pass the option
'--umask=000' to svlog. ***

That would be a good user interface, I think.

Ciao!

-- 
Ninety-eight percent of the adults in this country are decent,
hard-working, honest Americans. It's the other lousy two percent
that get all the publicity. But then--we elected them.
       -- Lily Tomlin

The Doctor What: Da Man
http://docwhat.gerf.org/
docwhat *at* gerf *dot* org
KF6VNC