become_root follow-up

[Luke Kenneth Casson Leighton]

On Sat, 21 Aug 1999, Michael Stockman wrote:

> Hello,
> 
> I would like to follow up on the become_root issue.
> 
> Doug VanLeuven, have you tried the consequenses of removing all
> become_root calls in the rpc_server directory (or even just those that
> you mentioned in your letter)? No, I will not ask you to remove every
> other become_root call.

:)
 
> Are we still thinking about how we would like the RPCs to work and how
> we are going to get there?

thinking?  i'm kinda waiting for someone to tell me (i.e you :)

> Did we reach a conclusion?

1) become_root() should be left around user password changes.

2) let's try it: if users are happy with it, leave it in.
  
> Luke, is there a design that tells which part of the RPC code (your
> code?) that is "library style" and which part is "application style"?
> Currently I've got no eagle's-eye over that code, but is quite lost in
> structures of function pointers and wrapper function back and forth.

ok.

rpc_parse/parse_*.c is used by both client and server to marshall and
unmarshall function call arguments into a flat data stream.

rpc_client/cli_*.c is client-side calls, used for example by
rpcclient/cmd_*.c and smbd/password.c.

rpc_server/srv_*.c is application instance implementations of the function
call made by cli_*.c.  you are probably being caught out by the use of
higher order function tables here, and the fact that the unmarshalling /
marshalling on server-side is also mixed in with the actual function
implementation.
 
> I would hate to see this issue living on yet several months without
> any apparent development.
> 
> With your permission I would like to submit a patch (smbd/uid.c
> head-version) that will keep samba from ending up root even if we have
> nested become_root calls (ignoring every but the first level). It is
> noted that this is no excuse not to track down every become_root
> problem reported.

good call.
 
> Best regards
>   Michael Stockman
>   pgmtekn-micke at algonet.se
> 
> 
> 
> begin 666 uid.patch
> M+2TM('5I9"YC+F]R:6<)1G)I($%U9R Q,R Q-SHT,3HP-R Q.3DY"BLK*R!U
> M:60N8PE&<FD at 075G(#(P(#(P.C,S.C$U(#$Y.3D*0$ @+3,V-BPQ-" K,S8V
> M+#$W($! "B J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
> M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PH@=F]I
> M9"!B96-O;65?<F]O="A"3T],('-A=F5?9&ER*2 *('L*+0EI9B H8F5C;VUE
> M7W)O;W1?9&5P=&@I('L*+0D)1$5"54<H,"PH(D524D]2.B!B96-O;64@<F]O
> M="!D97!T:"!I<R!N;VX@>F5R;UQN(BDI.PHK"2LK8F5C;VUE7W)O;W1?9&5P
> M=&@["BL)"BL):68@*&)E8V]M95]R;V]T7V1E<'1H("$](#$I('L**PD)1$5"
> M54<H,"PH(D524D]2.B!B96-O;64@<F]O="!D97!T:"!I<R E9"!S:&]U;&0@
> M8F4@,5QN(BP**PD)"6)E8V]M95]R;V]T7V1E<'1H*2D["BL)"7)E='5R;CL*
> M( E]"B ):68@*'-A=F5?9&ER*0H@"0ED;W-?1V5T5V0H8F5C;VUE7W)O;W1?
> M9&ER*3L*( H@"6-U<G)E;G1?=7-E<E]S879E9" ](&-U<G)E;G1?=7-E<CL*
> M+0EB96-O;65?<F]O=%]D97!T:" ](#$["B *( EB96-O;65?=6ED*# I.PH@
> M"6)E8V]M95]G:60H,"D["D! ("TS.#8L.2 K,S at Y+#$R($! "B J*BHJ*BHJ
> M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
> M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PH@=F]I9"!U;F)E8V]M95]R;V]T
> M*$)/3TP@<F5S=&]R95]D:7(I"B!["BT):68@*&)E8V]M95]R;V]T7V1E<'1H
> M("$](#$I('L*+0D)1$5"54<H,"PH(D524D]2.B!U;F)E8V]M92!R;V]T(&1E
> M<'1H(&ES("5D7&XB+ HK"2TM8F5C;VUE7W)O;W1?9&5P=&@["BL**PEI9B H
> M8F5C;VUE7W)O;W1?9&5P=&@@(3T@,"D@>PHK"0E$14)51R at P+"@B15)23U(Z
> M('5N8F5C;VUE(')O;W0 at 9&5P=&@@:7,@)60@<VAO=6QD(&)E(#!<;B(L"B )
> M"0D at 8F5C;VUE7W)O;W1?9&5P=&@I*3L**PD)<F5T=7)N.PH@"7T*( H@"2\J
> M('=E(&UI9VAT(&AA=F4 at 9&]N92!A(&)E8V]M95]U<V5R*"D@=VAI;&4@<G5N
> M;FEN9R!A<R!R;V]T+ I 0" M-#(R+#@@*S0R."PV($! "B )"61O<U]#:$1I
> M<BAB96-O;65?<F]O=%]D:7(I.PH@"B )8W5R<F5N=%]U<V5R(#T at 8W5R<F5N
> M=%]U<V5R7W-A=F5D.PHM"BT)8F5C;VUE7W)O;W1?9&5P=&@@/2 P.PH@?0H@
> #"B *
> `
> end
> 
> 

<a href="mailto:lkcl at samba.org"   > Luke Kenneth Casson Leighton    </a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network Development   </a>
<a href="http://samba.org"        > Samba Web site                  </a>
<a href="http://www.iss.net"      > Internet Security Systems, Inc. </a>