/proc doesn't work with Samba

[Cole, Timothy D.]

> -----Original Message-----
> From:	Dan Kaminsky [SMTP:effugas at best.com]
> Sent:	Thursday, June 24, 1999 18:05
> To:	timothy_d_cole at md.northgrum.com
> Cc:	samba-technical at samba.org
> Subject:	Re: /proc doesn't work with Samba
> 
> > >     **Why in the world would you want to share /proc???
> > > 
> > 	I suspect it's being shared as part of a share exporting the root
> > directory.  I usually use "dont descend" in these cases, anyway (i.e.
> for
> > /dev and /proc).  There are more convenience/saftey issues than there
> are
> > security issues, really:
> 
> No, actually I explicitly *want* remote access to /proc.  NT can get
> remote performance metrics from other NT machines; /proc is a cheap and
> *easy* way to get remote performance metrics from Unix machines for a
> 95/98/NT box.
> 
> > 	You generally don't want to be exporting /dev, as
> > user poking
> > around in Windows Explorer who happens, for instance, to have read
> access to
> > an auto-rewind tape device (i.e. they're some sort of demi-admin on the
> Unix
> > side) could end up suprising someone else when the tape drive tries to
> > rewind as the poor sap is in the middle of loading it... /dev,
> especially in
> > the Land of Big Iron, has just a little too much influence on the Real
> World
> > to be casually poked from Explorer.  I imagine opening /dev/zero in a
> text
> > editor might yield some interesting effects in your network, too.
> 
> If an Average User can break a tape drive,
> 
	Well, not an _average_ user.  It'd have to be someone who has
business with the tape drive.  Hopefully they'd normally be in communication
with the folks loading the tape, but that doesn't preclude stupid mistakes
when they're poking around in Explorer one day.

	And I was thinking more along the lines of damaging the tape and/or
the hapless operator's fingers.  The tape drive itself should be safe
enough.  Like I said, convenience/saftey, more than security.

>  that's the fault of the Unix
> Security Architecture.
> 
	More like the fault of the sysadmin, if an _average_ user can do
that.

> I mean, you don't blame vi if /etc/passwd is fully
> modifiable.
> 
	Nor do you blame the Unix Security Architecture :P

> > 	/proc can do some funky things to Explorer, too, if it tries to
> > recurse into it to compute directory sizes; think infinite recursion.
> 
> ls -R doesn't fail.  Neither does du, though I assume for different
> reasons.
> 
	No, same reason in fact.  "ls -R" doesn't follow symlinks down in
the tree, nor does straight "du".

	Explorer via Samba, however, will.  The /proc/<pid>/cwd entries can
be the biggest culprit, if you have any processes with a cwd in the root dir
or /proc (i.e. your smbd process)

> Something like a "limit infinite recurse" parameter might help.  
> 
	enh; maybe "recursion limit" would be a better name.  That might
actually be nice to have for other reasons, too, so long as nothing else was
hurt by implementing it.

	All this being said, you do have a really good reason to export
/proc ... I can't offhand think of a way to make dont descend apply to all
the /proc/<pid> directories, though.  I imagine you're interested in
/proc/interrupts and some other things out at the top level of /proc, or I'd
suggest you just export a subtree.  Since you're probably just doing this
for your own use, none of the /proc problems I mentioned before is really a
very serious issue, but it would be nice to be able to fix them even so.

	And there _is_ still the issue of Samba not behaving quite the way
you'd want for files that stat() reports as being 0 bytes in length.  Hrm...