| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- cleaned up some code
- Fixed a few memory leaks of my own making
- Add AddPrinterDriver(); I'm missing some of the semantics
here as the call is done correctly, but I'm not getting all
the information right in the DRIVER_INFO_3 struct I think.
Will work on it tomorrow some more...
--jerry
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the RPC code. This change was prompted by trying to save a long (>256)
character comment in the printer properties page.
The new system associates a TALLOC_CTX with the pipe struct, and frees
the pool on return of a complete PDU.
A global TALLOC_CTX is used for the odd buffer allocated in the BUFFERxx
code, and is freed in the main loop.
This code works with insure, and seems to be free of memory leaks and
crashes (so far) but there are probably the occasional problem with
code that uses UNISTRxx structs on the stack and expects them to contain
storage without doing a init_unistrXX().
This means that rpcclient will probably be horribly broken.
A TALLOC_CTX also needed associating with the struct cli_state also,
to make the prs_xx code there work.
The main interface change is the addition of a TALLOC_CTX to the
prs_init calls - used for dynamic allocation in the prs_XXX calls.
Now this is in place it should make dynamic allocation of all RPC
memory on unmarshall *much* easier to fix.
Jeremy.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the command line, the password would still be cached in memory
in plain text for the lifetime of the rpcclient command line session.
removed loopback connection functions from msrpc-client.c since
we don't support that in the server code now anyways. simplify,
simplify, ...
--jerry
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* fixes some readline bugs from the merge
* first attempt at commands (spoolenum almost works)
* no changes to existing functions in HEAD; only additions
of new functions. I'll weed out what I can as I go.
--jerry
|
| |
|
|
|
|
|
| |
semi-connection and a rpcclient prompt, but no functionality there yet.
Will be a few more days on that.
--jerry
|
| |
|
|
| |
msrpc loop-back interface.
|
| |
|
|
| |
to using internal msrpc code in smbd.
|
| |
|
|
| |
that were in the head branch but weren't in SAMBA_2_0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pdus, and then feeds them over either a "local" function call or a "remote"
function call to an msrpc service. the "remote" msrpc daemon, on the
other side of a unix socket, then calls the same "local" function that
smbd would, if the msrpc service were being run from inside smbd.
this allows a transition from local msrpc services (inside the same smbd
process) to remote (over a unix socket).
removed reference to pipes_struct in msrpc services. all msrpc processing
functions take rpcsrv_struct which is a structure containing state info
for the msrpc functions to decode and create pdus.
created become_vuser() which does everything not related to connection_struct
that become_user() does.
removed, as best i could, connection_struct dependencies from the nt spoolss
printing code.
todo: remove dcinfo from rpcsrv_struct because this stores NETLOGON-specific
info on a per-connection basis, and if the connection dies then so does
the info, and that's a fairly serious problem.
had to put pretty much everything that is in user_struct into parse_creds.c
to feed unix user info over to the msrpc daemons. why? because it's
expensive to do unix password/group database lookups, and it's definitely
expensive to do nt user profile lookups, not to mention pretty difficult
and if you did either of these it would introduce a complication /
unnecessary interdependency. so, send uid/gid/num_groups/gid_t* +
SID+num_rids+domain_group_rids* + unix username + nt username + nt domain
+ user session key etc. this is the MINIMUM info identified so far that's
actually implemented. missing bits include the called and calling
netbios names etc. (basically, anything that can be loaded into
standard_sub() and standard_sub_basic()...)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
damn, this one is bad.
started, at least two days ago, to add an authentication mechanism to
the smbd<->msrpc redirector/relay, such that sufficient unix / nt
information could be transferred across the unix socket to do a
become_user() on the other side of the socket.
it is necessary that the msrpc daemon inherit the same unix and nt
credentials as the smbd process from which it was spawned, until
such time as the msrpc daemon receives an authentication request
of its own, whereupon the msrpc daemon is responsible for authenticating
the new credentials and doing yet another become_user() etc sequence.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
one horrible cut / paste job from smbd, plus a code split of shared
components between the two.
the job is not _yet_ complete, as i need to be able to do a become_user()
call for security reasons. i picked lsarpcd first because you don't
_need_ security on it (microsoft botched so badly on this one, it's not
real. at least they fixed this in nt5 with restrictanonymous=0x2).
fixing this involves sending the current smb and unix credentials down
the unix pipe so that the daemon it eventually goes to can pick them
up at the other end.
i can't believe this all worked!!!
|
| |
|
