Samba under Coherant and Macintosh

Michael Stockman pgmtekn-micke at
Mon Dec 20 08:07:11 GMT 1999


> On Mon, 20 Dec 1999, Michael Stockman wrote:
> > Hello,
> >
> > > > why is it that you think that msrpc services don't need to do
> > 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
> > 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

> 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?

>  the only become_root()
> /unbecome_root() that allows _changes_ is the change user password
> and that is only allowed when the old user password has been
> all other modify-or-add password / group / alias API calls do not
have a
> become_root() / unbecome_root() around them, therefore the daemon
> already _Be_ root, and that requires the administrator SMB password.

Yes, and that is the way it should work. I hope you have removed that
awful code where you prevent the admin from setting the rights on the
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.

> > Maybe we should split it into two (or even more)
> > files sometime in the future, so that the admin could control who
> > see/change what based on unix file permissions?
> *sigh*.  that's exactly what i want to do, particularly as it's
> 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.

> however, andrew is in favour of only running as root and then doing
> control validation for everything.  i was planning the access
> validation as a later enhancement, and using reasonable
approximations in
> the mean-time.


> > PS. Though of the day: become_root is almost equal to
> > 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.

Best regards
  Michael Stockman
  pgmtekn-micke at

More information about the samba-technical mailing list