Samba under Coherant and Macintosh

[Luke Kenneth Casson Leighton]

On Mon, 20 Dec 1999, Michael Stockman wrote:

> Hello,
> 
> > On Mon, 20 Dec 1999, Michael Stockman wrote:
> >
> > > Hello,
> > >
> > > > > why is it that you think that msrpc services don't need to do
> file
> > > access?
> > > > > what about access to private/smbpasswd from samrd?
> > > >
> > > > we do become_root() before those anyway, so thats totally
> > > > irrelevant. (the smbpasswd can _only_ be accessed as root).
> > >
> > > Don't, pretty please. become_root must only be used when samba is
> > > collecting data for internal use. It is not acceptable that samba
> > > return any data that a user would not have access to if logged in
> to
> > > the machine while samba isn't running.
> >
> > so, how should a user change their own password?  this is the only
> way (at
> > present).
> 
> If so, then it is a valid place, and I do say nothing about that
> usage.
> 
> > actually, at present, we do a become_root() / unbecome_root() around
> > anything that provides read-only samr info.
> 
> This is not a valid point. Why? Because the user wouldn't be able to
> read this with ed or anything else when logged into the computer. If
> s/he were, why would you need the become_root?

to provide the  exact same [in]security that NT provides.  there _is_ a
technical reason for this, which is that the show users on file security
would fail if you didn't.
 
> >  the only become_root()
> > /unbecome_root() that allows _changes_ is the change user password
> call,
> > and that is only allowed when the old user password has been
> validated.
> > all other modify-or-add password / group / alias API calls do not
> have a
> > become_root() / unbecome_root() around them, therefore the daemon
> must
> > already _Be_ root, and that requires the administrator SMB password.
> 
> Yes, and that is the way it should work. 

i agree.  andrew does not.

> I hope you have removed that
> awful code where you prevent the admin from setting the rights on the
> file,

i do not understand.  what awful code, what rights, and what file?

> as the group adm (or wheel or root or some custom name) could
> like read/write access to it (like domain admins:).
> 
> > > Why are you so against allowing the administrator control who has
> > > access to smbpasswd?
> >
> > i am?  what makes you think that?
> 
> My note above.

sorry, i don't get it.
 
> > > Maybe we should split it into two (or even more)
> > > files sometime in the future, so that the admin could control who
> can
> > > see/change what based on unix file permissions?
> >
> > *sigh*.  that's exactly what i want to do, particularly as it's
> already
> > what's used in 2.0.X and 2.1prealpha.
> 
> Two months ago, that would have been a truth with modification. I
> don't know if it has changed.

it certainly hasn't in 2.1prealpha.  i can pretty much guarantee that it
hasn't in 2.0.x.

> > > PS. Though of the day: become_root is almost equal to
> become_rotten,
> > > if used badly ;).
> >
> > not quite.  from what i understand of what andrew was saying, how
> are you
> > going to stop people, say, from abusing potential race conditions
> on, say,
> > log files?
> 
> You are not differing between the valid points and the invalid points
> of usage.

those points, in your opinion being...

please explain, i obviously don't get it.  sorry!