From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1243 Path: news.gmane.org!not-for-mail From: Christian Holtje Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: svlogd and umask settings Date: Mon, 18 Sep 2006 11:18:37 -0400 Message-ID: <450EB8CD.2050800@docwhat.gerf.org> References: <20060830220325.GK25489@annvix.org> <20060901174940.GY25489@annvix.org> <20060915144744.18045.qmail@3430f19bcf16f5.315fe32.mid.smarden.org> <20060915152226.GI18873@annvix.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1158592753 23277 80.91.229.2 (18 Sep 2006 15:19:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Sep 2006 15:19:13 +0000 (UTC) Original-X-From: supervision-return-1479-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Sep 18 17:19:09 2006 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1GPKtM-0006Jv-PH for gcsg-supervision@gmane.org; Mon, 18 Sep 2006 17:18:40 +0200 Original-Received: (qmail 21591 invoked by uid 76); 18 Sep 2006 15:19:01 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 21585 invoked from network); 18 Sep 2006 15:19:01 -0000 User-Agent: Thunderbird 1.5.0.7 (X11/20060909) Original-To: supervision@list.skarnet.org In-Reply-To: <20060915152226.GI18873@annvix.org> X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on gerf.org X-Virus-Status: Clean Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1243 Archived-At: Vincent Danen wrote: > * Gerrit Pape [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