From owner-svn-src-user@FreeBSD.ORG Fri Feb 27 19:53:40 2015
Return-Path: <owner-svn-src-user@FreeBSD.ORG>
Delivered-To: svn-src-user@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id 8BB46494;
Fri, 27 Feb 2015 19:53:40 +0000 (UTC)
Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru
[78.107.232.239])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "dchagin.static.corbina.net",
Issuer "dchagin.static.corbina.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id E9D03FB7;
Fri, 27 Feb 2015 19:53:38 +0000 (UTC)
Received: from dchagin.static.corbina.net (localhost [127.0.0.1])
by dchagin.static.corbina.net (8.14.9/8.14.9) with ESMTP id t1RJrTIY008027
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Fri, 27 Feb 2015 22:53:29 +0300 (MSK)
(envelope-from dchagin@dchagin.static.corbina.net)
Received: (from dchagin@localhost)
by dchagin.static.corbina.net (8.14.9/8.14.9/Submit) id t1RJrTNV008026;
Fri, 27 Feb 2015 22:53:29 +0300 (MSK) (envelope-from dchagin)
Date: Fri, 27 Feb 2015 22:53:29 +0300
From: Chagin Dmitry <dchagin@freebsd.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Subject: Re: svn commit: r279335 - in user/dchagin/lemul/sys:
compat/linprocfs fs/procfs fs/pseudofs modules/procfs
Message-ID: <20150227195329.GA7995@dchagin.static.corbina.net>
References: <201502262130.t1QLUfwf027872@svn.freebsd.org>
<20150226220342.GC3799@dft-labs.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150226220342.GC3799@dft-labs.eu>
User-Agent: Mutt/1.5.23 (2014-03-12)
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" <svn-src-user.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-user>,
<mailto:svn-src-user-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-user/>
List-Post: <mailto:svn-src-user@freebsd.org>
List-Help: <mailto:svn-src-user-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>,
<mailto:svn-src-user-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2015 19:53:40 -0000
On Thu, Feb 26, 2015 at 11:03:42PM +0100, Mateusz Guzik wrote:
> 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.
>
pfs_readlink does a PHOLD and PRELE around calling fill method, is
this not enought?
> 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.
ok, give me see the patch, pls.
--
Have fun!
chd