* Christian Holtje <list.supervision@docwhat.gerf.org> [2006-09-18 11:18:37 -0400]:

> >>>> 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.

Yup, true.  But svlogd would need to be aware of umask settings... right
now it doesn't care and writes files mode 0744 or 0644; either way it's
not creating 0777 files nor is it even bothering to look at the umask.

> 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.

It would first need svlogd caring about umask settings... =)

But I agree.  I'd like to see either a switch to specify log perms or
svlogd using umask settings (and doing the sanity check you note above).

-- 
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)