From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1244 Path: news.gmane.org!not-for-mail From: Vincent Danen Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: svlogd and umask settings Date: Mon, 18 Sep 2006 10:06:27 -0600 Organization: Annvix Message-ID: <20060918160627.GC2128@annvix.org> References: <20060830220325.GK25489@annvix.org> <20060901174940.GY25489@annvix.org> <20060915144744.18045.qmail@3430f19bcf16f5.315fe32.mid.smarden.org> <20060915152226.GI18873@annvix.org> <450EB8CD.2050800@docwhat.gerf.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" X-Trace: sea.gmane.org 1158595635 3587 80.91.229.2 (18 Sep 2006 16:07:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Sep 2006 16:07:15 +0000 (UTC) Cc: supervision@list.skarnet.org Original-X-From: supervision-return-1480-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Sep 18 18:07:14 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 1GPLeB-0003z7-Hf for gcsg-supervision@gmane.org; Mon, 18 Sep 2006 18:07:03 +0200 Original-Received: (qmail 23478 invoked by uid 76); 18 Sep 2006 16:07:24 -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 23471 invoked from network); 18 Sep 2006 16:07:24 -0000 Original-To: Christian Holtje Content-Disposition: inline In-Reply-To: <450EB8CD.2050800@docwhat.gerf.org> X-Mailer: Mutt 1.5.x/OS X 10.4.x X-PGP-Key: http://linsec.ca/vdanen.asc X-URL: http://annvix.org/ User-Agent: Mutt/1.5.10i X-SA-Exim-Connect-IP: 68.149.37.7 X-SA-Exim-Mail-From: vdanen@annvix.org X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on hades.annvix.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-SA-Exim-Version: 4.2 (built Wed, 01 Feb 2006 18:29:36 -0700) X-SA-Exim-Scanned: Yes (on hades.annvix.org) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1244 Archived-At: --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Christian Holtje [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 uma= sk > >>>> 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 fil= es > >>>> 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 lo= gs > >>>> 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 fil= es > >>> 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? svlo= gd > >> won't touch these settings. > >=20 > > I could, yes, but it just seems wrong to me. =3D) 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). > >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > 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=3D000' to svlog. *** >=20 > That would be a good user interface, I think. It would first need svlogd caring about umask settings... =3D) 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). --=20 {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFDsQDLrxeMv7jCtQRAmdoAJ9osdg0iVIHUTvFNlzINC+O/eU0OACdFUet ToyrjN2Jq1IZn7J0B1aIKlM= =0jfq -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG--