IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
rewrote the printer notify code, so now it's compatible with SP5 and fully
dynamic. No more limits on printers and job lists.
removed the make_xxx() functions as they are not used and broken
fixed a bug in the open handle function.
J.F.
OpenPrinterEx is now decoding correctly the query
most of the EnumXXX use the new_buffer struct.
check the (un)marshalling return code.
conclusion: still a long way to go. all the client code has to be
rewritten, and I still wonder how to implement correctly the notify stuff.
is *missing* from samba cvs main, therefore it is set to all zeros.
this will cause, amongst other things, administrator-changing-user-passwords,
and setting up new accounts, to fail, as the user's password can only be
decoded with the session key (in this case, the administrator's usr sess key).
it's never a perfect world, is it?
done a minimal amout of clean-up in the Makefile, removing unnecessary
modules from the link stage. this is not complete, yet, and will
involve some changes, for example to smbd, to remove dependencies on
the password database API that shouldn't be there. for example,
smbd should not ever call getsmbpwXXX() it should call the Samr or Lsa
API.
this first implementation has minor problems with not reinstantiating
the same services as the caller. the "homes" service is a good example.
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()...)
at present, a unix password is missing from the unix credentials, but is
not _actually_ expected to be needed. weeelll... maybe :-)
this is used to transfer credentials between smbd and msrpc daemons, down
a unix socket, so that the unix and nt credentials can be inherited by
an msrpc daemon called up from smbd.
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!!!
if microsoft bothered to publish it. actually, there are good reasons
for not publishing it: people might write programs for it, and then
those programs wouldn't work on nt5, for example...
some of the server-side stuff. Realloc() was being used, so it
Realloc()d some random area of memory. oops.dynamic memory allocation i added a month ago: forgot to ZERO_STRUCT()
some of the server-side stuff. Realloc() was being used, so it
Realloc()d some random area of memory. oops.dynamic memory allocation i added a month ago: forgot to ZERO_STRUCT()
some of the server-side stuff. Realloc() was being used, so it
Realloc()d some random area of memory. oops.
have the string max length = string length + 1.
if not, then it gets its knickers in a twist over whether the string
is NULL-terminated or not.
four days.
four days i spent on this one.
reg_io_r_info() working properly. previously they weren't well
understood (well, they were the first of the registry functions i did,
back in december 97, ok??? :-)
set ntversion to 0x1 in SAMQUERY, so that we reply same as NT4 srv.
these _may_ not actually ever get used, as trust relationships
really need to be established with shared secrets, and you need
to get the SID of the trusted and trusting domains, so this
may have to go in a private/xxx.mac file.
for which a PDC is responsible. typical answers are:
<Name of Domain> plus <Builtin>.
against a hierarchical, down-level-compatible NT5 PDC, there's likely to
be more than these two entries!!!!!
- disabled (AGAIN) the GETDC "if (MAILSLOT\NTLOGON)" code that will get
NT5rc2 to work but WILL break win95 (AGAIN). this needs _not_ to be
re-enabled but to be replaced with a better mechanism.
- added SMBwrite support (note: SMBwriteX already existed) as NT5rc2 is
sending DCE/RPC over SMBwrite not SMBwriteX.
