CVS update: samba/source/include (fwd)

[Cole, Timothy D.]

> -----Original Message-----
> From:	bs at niggard.org [SMTP:bs at niggard.org]
> Sent:	Friday, December 17, 1999 19:02
> To:	Multiple recipients of list SAMBA-NTDOM
> Subject:	Re: CVS update: samba/source/include (fwd)
> 
> 
> On Sat, 18 Dec 1999, Gerald Carter wrote:
> 
> > Luke Kenneth Casson Leighton wrote:
> > > 
> > > if you don't speak up in favour, start/stop services as remote
> > > administrator certainly won't ever get added.  if you are just
> > > a unix admin and do not touch NT or do not use any remote unix
> > > administrative tools with the similar capability [to start/stop
> > > services], please say so, and your opinion will be noted but 
> > > given less weight.
> >
> > I've stated this before, but I've really got to agree with 
> > Andrew.  I think this is a bad idea in production.  This is 
> > a gut feeling.  Just for the record, bad idea....
> 
> It sure is a bad idea in production. Do not include it in samba. Whats
> wrong with an external, unsupported module? Why is it better to allow
> starting/stopping over http?
> 
	From the perspective of a Unix admin, I don't like this idea one bit
either; it really amounts to a mixing of security models, which almost
invariably has unformseen side-effects.  HOWEVER, there are Samba
installations right now that aren't really being used as Unix boxes, per se
-- just a little black box sitting there serving SMB and maybe a couple
other protocols, trying to look like an NT box on the NT network.  In those
cases, it's expected (and IMO fairly important) for services control and
other administrative facilities to behave just like NT.

	Really, as highlighted in the discussion over security mask/create
mask a while back, there are two very very different sets of demands WRT
security and functionality when you compare Samba on a Unix box being used
as a Unix box to Samba on a Unix box being used as an NT-like "opaque
server" box.  NT RPC control of services is (in most cases) an extremely bad
idea in the former case, but in the latter case, it's desirable and almost
necessary.

	So, in conclusion, I think this functionality should be added, but
with the following caveats:

	 1. the code for this functionality should not be built by default,
requiring a compile-time option to turn on.  security warning at
./configure-time wouldn't hurt, too

	 2. it should be separated as much as possible into its own
module/library/executable, such that it can be removed/uninstalled after
compile-time

	 3. even when compiled and installed, it should not be enabled at
runtime except when explicitly enabled in the configuration file

	 4. there needs to be a well-defined and fairly paranoid access
control mechanism (I would hope this is already more or less covered by the
NT security model, but...).  I'd like to see Luke go into the details and
implications of this before the feature is implemented.

	 5. control should only extend (by default) to the Samba daemons
(yes, I realize that there is a potential chicken-and-egg problem there WRT
starting services, but there are some circumstances under which it may still
be desirable).  control of additional services should require third-party
packages (i.e. init.d-like scripts [but not init.d scripts]), which we would
not ship with Samba

	The idea here being that only people who have a compelling need for
this functionality (primarily the makers of these "standalone" systems) will
be determined enough to jump through the hoops to set up, while not making
it impossible for them to obtain (they WILL want it).  At the same time,
it's not going to be something that Joe admin will be able to idly turn on
one day when he feels like experimenting.