Samba under Coherant and Macintosh
Luke Kenneth Casson Leighton
lkcl at samba.org
Mon Dec 20 16:24:13 GMT 1999
On Mon, 20 Dec 1999, Michael Stockman wrote:
> > 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?
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
> > 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 agree. andrew does not.
> I hope you have removed that
> awful code where you prevent the admin from setting the rights on the
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
> > > 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.
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
> > > 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!
More information about the samba-technical