From owner-freebsd-fs@FreeBSD.ORG Sun May 20 18:23:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B35316A46C for ; Sun, 20 May 2007 18:23:10 +0000 (UTC) (envelope-from tamaru@myn.rcast.u-tokyo.ac.jp) Received: from mail1.ecc.u-tokyo.ac.jp (mail1.ecc.u-tokyo.ac.jp [133.11.50.203]) by mx1.freebsd.org (Postfix) with ESMTP id 6758A13C4DE for ; Sun, 20 May 2007 18:23:09 +0000 (UTC) (envelope-from tamaru@myn.rcast.u-tokyo.ac.jp) Received: from spam004.ecc.u-tokyo.ac.jp (spam004.ecc.u-tokyo.ac.jp [133.11.50.197]) by mail1.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id 144AA2A2AE2 for ; Mon, 21 May 2007 03:23:08 +0900 (JST) Received: from gin.myn.rcast.u-tokyo.ac.jp (157.82.72.158 [157.82.72.158]) by spam004.ecc.u-tokyo.ac.jp (SpamBlock.pst 3.4.97) with ESMTP id for ; Mon, 21 May 2007 03:22:47 +0900 Date: Mon, 21 May 2007 03:22:46 +0900 Message-ID: From: Hiroharu Tamaru To: "Zane C.B." In-Reply-To: <20070520134645.3d77b75c@vixen42> References: <20070519222527.680ba5c2@vixen42> <20070520123607.4aba7f35@vixen42> <20070520131042.2ce78ae0@vixen42> <20070520134645.3d77b75c@vixen42> User-Agent: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-IP: 157.82.72.158 X-FROM-DOMAIN: myn.rcast.u-tokyo.ac.jp X-FROM-EMAIL: tamaru@myn.rcast.u-tokyo.ac.jp Cc: freebsd-fs@freebsd.org Subject: Re: mount_smbfs and non-interactively passing a password to it X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2007 18:23:10 -0000 At Sun, 20 May 2007 13:46:45 -0400, Zane C.B. wrote: > > On Mon, 21 May 2007 02:39:17 +0900 > Hiroharu Tamaru wrote: > > > At Sun, 20 May 2007 13:10:42 -0400, Zane C.B. wrote: > > > > > > On Mon, 21 May 2007 01:58:58 +0900 > > > Hiroharu Tamaru wrote: > > > > > > > At Sun, 20 May 2007 12:36:07 -0400, Zane C.B. wrote: > > > > > > > > > > On Mon, 21 May 2007 01:19:58 +0900 > > > > > Hiroharu Tamaru wrote: > > > > > > > > > > > > > > > > > At Sat, 19 May 2007 22:25:27 -0400, Zane C.B. wrote: > > > > > > > Is passing a password to mount_smbfs non-interactively > > > > > > > possible? I know it can't accept it on STDIN by piping it > > > > > > > into it. > > > > > > > > > > > > mount_smbfs(8) : > > > > > > -N Do not ask for a password. At run time, > > > > > > mount_smbfs reads the ~/.nsmbrc file for additional > > > > > > configuration parameters and a password. If no password is > > > > > > found, mount_smbfs prompts for it. > > > > > > > > > > > > /usr/share/examples/smbfs/dot.nsmbrc : > > > > > > [FSERVER:JOE] > > > > > > # use persistent password cache for user 'joe' > > > > > > password=$$1767877DF > > > > > > > > > > > > I'm using -N for shares w/o passwords; I've never > > > > > > tried .nsmbrc password myself > > > > > > > > > > This is not useful if ~/ is not mounted and you are planning > > > > > of mounting it using mount_smbfs. > > > > > > > > You never said that. > > > > Who's mounting ~user in that case? root? > > > > > > Yeah, looking at doing it through PAM. > > > > OK. finally, I see your picture and why you said ENV; > > > > For a hack: > > With the root creds in effect, /root/.nsmbrc is consulted > > and /etc/nsmb.conf is always consulted (as written in that file). > > Write the password in either of it, mount, and wipe it out. > > Not useful since that would require passwords being in that file. Yeah, I well see that the password lives longer if a file is used (even if you symlink it onto a memory file system), but root can always peek inside the memory as well, and root can often intercept syscalls as well. Anyway, that's why I called it a hack. > > Other than that, I've no idea. > > You'd need to wipe out the environment vars if you use it too. > > Decided against that since D.E.S. pointed out that it would be > exposed in /proc. Yeah, I thought it'd be tough too. If you are going to modify mount_smbfs anyway, you could give it a pipe or a socket as an ARG or ENV, or have it unnamed and inherit it? The password is then send via the pipe or the socket. FWIW, IIRC, some version of ssh-agent used unnamed socket or pipe to limit its access to its descendants only. I don't know if the reason for the change of that enforcement was security-wise or not.