From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2047 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.comp.sysutils.supervision.general,gmane.comp.tools.sudo.user Subject: Re: Improper setting / resetting of the signals mask Date: Tue, 14 Sep 2010 22:22:23 +0200 Message-ID: <20100914202223.GA10388@skarnet.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1284495629 28184 80.91.229.12 (14 Sep 2010 20:20:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 20:20:29 +0000 (UTC) Cc: supervision@list.skarnet.org, sudo-users@sudo.ws To: "Ciprian Dorin, Craciun" Original-X-From: supervision-return-2281-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Sep 14 22:20:27 2010 Return-path: Envelope-to: gcsg-supervision@lo.gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1OvbzP-0005iH-Jx for gcsg-supervision@lo.gmane.org; Tue, 14 Sep 2010 22:20:27 +0200 Original-Received: (qmail 16606 invoked by uid 76); 14 Sep 2010 20:22:23 -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 16596 invoked by uid 1000); 14 Sep 2010 20:22:23 -0000 Mail-Followup-To: supervision@list.skarnet.org, sudo-users@sudo.ws, ciprian.craciun@gmail.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2047 gmane.comp.tools.sudo.user:3367 Archived-At: > Hello all! > > Sorry for cross-posting, but this "bug" is relevant to both > projects (`runit` and `sudo`), so please forgive me in advance. :) > > In short `sudo` doesn't seem to reset (zero out) its inherited > signal mask, and `runit` seems to leave some signals blocked when > exec-ing children. (And the side-effect is breaking some service > management scripts.) Hello Ciprian, If you're going to blame sudo for not resetting the signal mask, why not also blame bash, which is executed between runsv and sudo ? :) It seems natural to think that a shell should reset the sigprocmask. I just checked SUSv3, which says nothing about that; so, by default, ignoring the sigprocmask is probably the right thing to do, and bash (for once) gets it right. It is debatable whether sudo should be paranoid and also unblock signals. On the one hand, the *point* of sudo is to be paranoid. On the other hand, applications can and generally should expect to be executed in a sane environment, and be liberal in what they accept (i.e. they should not arbitrarily close fds or remove environment variables, for instance - and I don't think they should arbitrarily unblock signals either). What is certain is that runsv does the wrong thing here: blocked signals should definitely be unblocked before exec'ing an external command. I'm sure Gerrit will agree and fix that in a next release. In the meantime, let me suggest 2 workarounds: - You can use the 'trap' shell command to manually unblock signals. SUSv3 does not even specify that using 'trap' should unblock the trapped, or defaulted, signals, but not doing it would be clearly absurd. 'trap - TERM' and you should be rolling. - In this precise case, you don't even need sudo. If all you want is to give user 'joe' enough rights to control /service/foo, you can make /service/foo/supervise/control writable by 'joe'. For instance: # chown joe /service/foo/supervise/control Then, no need for elaborate control scripts: all the complexity of the script can be moved to the client side, and joe just runs 'sv force-restart /service/foo' when appropriate. -- Laurent