From patchwork Wed Jun 22 06:38:52 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 903632 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5M6d7JC007999 for ; Wed, 22 Jun 2011 06:39:07 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753372Ab1FVGjF (ORCPT ); Wed, 22 Jun 2011 02:39:05 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53179 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752314Ab1FVGjE (ORCPT ); Wed, 22 Jun 2011 02:39:04 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id F2F9F8AD27; Wed, 22 Jun 2011 08:39:02 +0200 (CEST) Date: Wed, 22 Jun 2011 16:38:52 +1000 From: NeilBrown To: Steve Dickson , linux-nfs@vger.kernel.org Subject: [PATCH/RFC] mount: improve signal management when locking mtab. Message-ID: <20110622163852.71a2ae80@notabene.brown> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Wed, 22 Jun 2011 06:39:07 +0000 (UTC) From: Neil Brown Date: Wed, 22 Jun 2011 16:15:45 +1000 Subject: [PATCH] mount: improve signal management when locking mtab. As mount.nfs can run setuid it must be careful about how the user can interact with in. In particular it needs to ensure it does not respond badly to any signals that the user might be able to generate. This is particularly an issue while updating /etc/mtab (when that is not linked to /proc/mounts). If the user can generate a signal which kills mount.nfs while /etc/mtab is locked, then it will leave the file locked, and could possibly corrupt mtab (particularly if 'ulimit 1' was previously issued). Currently lock_mtab does set some handlers for signals, but not enough. It arranges for every signal up to (but not including) SIGCHLD to cause mount.nfs to unlock mdadm promptly exit ... even if the default behaviour would be to ignore the signal. SIGALRM is handled specially, and signals after SIGCHLD are left with their default behaviour. This includes for example SIGXFSZ which can be generated by the user running "ulimit 1". So: change this so that some signals are left unchanged, SIGALRM is handled as required, and all signals that the user can generate are explicitly ignored. The remainder still cause mount.nfs to print a message, unlock mtab, and exit. Signed-off-by: NeilBrown --- utils/mount/fstab.c | 37 ++++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 5 deletions(-) diff --git a/utils/mount/fstab.c b/utils/mount/fstab.c index a742e64..1fc9efe 100644 --- a/utils/mount/fstab.c +++ b/utils/mount/fstab.c @@ -331,16 +331,43 @@ lock_mtab (void) { int sig = 0; struct sigaction sa; - sa.sa_handler = handler; sa.sa_flags = 0; sigfillset (&sa.sa_mask); - while (sigismember (&sa.sa_mask, ++sig) != -1 - && sig != SIGCHLD) { - if (sig == SIGALRM) + while (sigismember (&sa.sa_mask, ++sig) != -1) { + switch(sig) { + case SIGCHLD: + case SIGKILL: + case SIGCONT: + case SIGSTOP: + /* The cannot be caught, or should not, + * so don't even try. + */ + continue; + case SIGALRM: sa.sa_handler = setlkw_timeout; - else + break; + case SIGHUP: + case SIGINT: + case SIGQUIT: + case SIGWINCH: + case SIGTSTP: + case SIGTTIN: + case SIGTTOU: + case SIGPIPE: + case SIGXFSZ: + case SIGXCPU: + /* non-priv user can cause these to be + * generated, so ignore them. + */ + sa.sa_handler = SIG_IGN; + break; + default: + /* The rest should not be possible, so just + * print a message and unlock mtab. + */ sa.sa_handler = handler; + } sigaction (sig, &sa, (struct sigaction *) 0); } signals_have_been_setup = 1;