From owner-svn-src-user@FreeBSD.ORG Thu Feb 26 22:03:48 2015 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC02F5D8; Thu, 26 Feb 2015 22:03:48 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A2E1E14; Thu, 26 Feb 2015 22:03:48 +0000 (UTC) Received: by wghl2 with SMTP id l2so15244355wgh.9; Thu, 26 Feb 2015 14:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/FI7aeZ82CG/KpFAZyXYqiurFHV1x06YJZgksPDE9Aw=; b=NU3PykUljg3c7k55vqqz+3I3y5DE73GbINREBDt4Xuub7c5UYij1RtsOC0oAGIfIV9 25GtmE3I15hMLoLAcQjE6Fwi+1K3IGMWndrAwzXSYWAyRc0QY+NOrHDRIBtMNRlArP0c MeY3J8JazhbS0ztg+/a52xnglsQSjql8ZPYdJDavzxeZwKU1MD3NLomW1VTxaP45UwEi 7fImvTaW6hNHmjgMuL0wEEdi9CHi6b8c1uooRQmrP6Zmu99Tc0TLPidQNsGlWUBZMsvC VzZAARnvnpJAggvhMg1OAp2uHtjYwtQPi/xpe1f3d5PLWnZOawBUmmGwBzgMRyb5UsSL /s/A== X-Received: by 10.180.103.102 with SMTP id fv6mr282022wib.80.1424988225871; Thu, 26 Feb 2015 14:03:45 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id k1sm3250261wjn.9.2015.02.26.14.03.44 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 26 Feb 2015 14:03:44 -0800 (PST) Date: Thu, 26 Feb 2015 23:03:42 +0100 From: Mateusz Guzik To: Dmitry Chagin Subject: Re: svn commit: r279335 - in user/dchagin/lemul/sys: compat/linprocfs fs/procfs fs/pseudofs modules/procfs Message-ID: <20150226220342.GC3799@dft-labs.eu> References: <201502262130.t1QLUfwf027872@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201502262130.t1QLUfwf027872@svn.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:03:49 -0000 On Thu, Feb 26, 2015 at 09:30:41PM +0000, Dmitry Chagin wrote: > +int > +procfs_dofdlink(PFS_FILL_ARGS) > +{ > + char *fullpath, *freepath, *endfileno; > + struct filedesc *fdp; > + struct vnode *vp; > + struct file *fp; > + int fileno, error; > + > + if (vnode_name == NULL) > + return (ENOENT); > + > + fileno = (int)strtol(vnode_name, &endfileno, 10); > + if (fileno == 0 && (vnode_namelen > 1 || > + (vnode_namelen == 1 && vnode_name[0] != '0'))) > + return (ENOENT); > + if (vnode_namelen != endfileno - vnode_name) > + return (ENOENT); > + > + fdp = fdhold(p); > + if (fdp == NULL) > + return (ENOENT); > + > + error = fget_unlocked(fdp, fileno, NULL, &fp, NULL); > + if (error != 0) > + goto out; > + > + freepath = NULL; > + fullpath = "-"; > + vp = fp->f_vnode; > + if (vp != NULL) { > + vref(vp); > + error = vn_fullpath(td, vp, &fullpath, &freepath); > + vrele(vp); > + } > + if (error == 0) > + error = sbuf_printf(sb, "%s", fullpath); > + if (freepath != NULL) > + free(freepath, M_TEMP); > + fdrop(fp, td); > + > + out: > + fddrop(fdp); > + return (error); > +} > fdhold does not protect file descriptor table, it only makes sure struct filedesc itself is not freed. Here you need to lock it and inspect fd_refcnt. See e.g. kern_proc_filedesc_out. While this guarantees data consistency, is in fact still incorrect since the process you are inspecing can exec setuid in the meantime and thus make security checks (if any performed) stale. I have an old WIP patch which provides appropriate interfaces to ensure stability of the process (no exit, no exec), but this needs additional changes. HOpefully i'll have the time to deal with it in March. -- Mateusz Guzik