mount_smbfs and non-interactively passing a password to it

[Hiroharu Tamaru]

At Sun, 20 May 2007 13:46:45 -0400,
Zane C.B. wrote:
> 
> On Mon, 21 May 2007 02:39:17 +0900
> Hiroharu Tamaru <tamaru at myn.rcast.u-tokyo.ac.jp> 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 <tamaru at myn.rcast.u-tokyo.ac.jp> 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 <tamaru at myn.rcast.u-tokyo.ac.jp> 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.