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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
a byte range lock (write lock only, but Win2k breaks on read lock also so I
do the same) - if you think about why, this is obvious. Also fixed our client
code to do level II oplocks, if requested, and fixed the code where we would
assume the client wanted level II if it advertised itself as being level II
capable - it may not want that.
Jeremy.
(This used to be commit 213cd0b519)
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.
(This used to be commit 0ff2ce543e)
semi-connection and a rpcclient prompt, but no functionality there yet.
Will be a few more days on that.
These files changed only with the addition of some support functions
from TNG
--jerry
(This used to be commit a04ea15f72)
assumption that we have one socket everywhere
while doing so I discovered a few bugs!
1) the clientgen session retarget code if used from smbd or nmbd would
cause a crash as it called close_sockets() which closed our main
socket! fixed by removing close_sockets() completely - it is unnecessary
2) the caching in client_addr() and client_name() was bogus - it could
easily get fooled and give the wrong result. fixed.
3) the retarget could could recurse, allowing an easy denial of
service attack on nmbd. fixed.
(This used to be commit 5937ab14d2)
libsmb/clientgen.c: Fixes for Win2k smbclient browsing.
Other fixes implement smbpasswd -x user to delete users. Also allows swat
to do the same.
Jeremy.
(This used to be commit 9f6ad04676)
nmbd/nmbd_processlogon.c: Use "True" and "False" instead of 1 and 0.
Others - preparing for multiple pdu write code.
Jeremy.
(This used to be commit 9f879ec396)
the last piece was to use a smb timeout slightly larger than the
locking timeout in bloking locks to prevent a race
(This used to be commit 1b54cb4a33)
we now don't pass the lock type at all for unlocks.
I was surprised to discover that NT totally ignores the lock type in
unlocks. It unlocks a matching write lock if there is one, otherwise
it removes the first matching read lock.
(This used to be commit 1bbc1ce18b)
that will make us match NT semantics exactly and do away with the
horrible fd multiplexing in smbd.
this is some diag stuff to get me started.
- added the ability to do read or write locks in clientgen.c
- added a LOCK4 test to smbtorture. This produces a report on the server
and its locking capabilities. For example, NT4 gives this:
the same process cannot set overlapping write locks
the same process can set overlapping read locks
a different connection cannot set overlapping write locks
a different connection can set overlapping read locks
a different pid cannot set overlapping write locks
a different pid can set overlapping read locks
the same process can set the same read lock twice
the same process cannot set the same write lock twice
the same process cannot override a read lock with a write lock
the same process can override a write lock with a read lock
a different pid cannot override a write lock with a read lock
the same process cannot coalesce read locks
this server does strict write locking
this server does strict read locking
whereas Samba currently gives this:
the same process can set overlapping write locks
the same process can set overlapping read locks
a different connection cannot set overlapping write locks
a different connection can set overlapping read locks
a different pid can set overlapping write locks
a different pid can set overlapping read locks
the same process can set the same read lock twice
the same process can set the same write lock twice
the same process can override a read lock with a write lock
the same process can override a write lock with a read lock
a different pid can override a write lock with a read lock
the same process can coalesce read locks
this server does strict write locking
this server does strict read locking
win95 gives this - I don't understand why!
the same process cannot set overlapping write locks
the same process cannot set overlapping read locks
a different connection cannot set overlapping write locks
a different connection cannot set overlapping read locks
a different pid cannot set overlapping write locks
a different pid cannot set overlapping read locks
the same process cannot set the same read lock twice
the same process cannot set the same write lock twice
the same process cannot override a read lock with a write lock
the same process cannot override a write lock with a read lock
a different pid cannot override a write lock with a read lock
the same process cannot coalesce read locks
this server does strict write locking
this server does strict read locking
(This used to be commit 49637936b6)
After fixing that I needed to use O_RDWR instead of O_WRONLY in
several places to avoid the silly bug in MS servers that doesn't allow
getattrE on a file opened with O_WRONLY
(This used to be commit e21aa4cb08)
This fixes our netbios scope handling. We now have a 'netbios scope' option
in smb.conf and the scope option is removed from make_nmb_name()
this was prompted by a bug in our PDC finding code where it didn't append
the scope to the query of the '*' name.
(This used to be commit b563be824b)
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.
(This used to be commit caa5052522)
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()...)
(This used to be commit aa3c659a8d)
time out of sending the session setup on Solaris 2.6. No idea.
I'll work on it some tomorrow. This is to fix the "Unable to
setup password vectors" thingy.
Also changed an inet_aton() to inet_addr() as the former is
not very portable :-)
Luke, I set the redir flag to false because the connection to
the smb-agent was failing and smbpasswd bombed. Double check me
on this one.
-jc
(This used to be commit e1d2b174ca)
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.
(This used to be commit 30c7fdd6ef)
created an "nmb-agent" utility that, yes: it connects to the 137 socket
and accepts unix socket connections which it redirects onto port 137.
it uses the name_trn_id field to filter requests to the correct
location.
name_query() and name_status() are the first victims to use this
feature (by specifying a file descriptor of -1).
(This used to be commit d923bc8da2)
moved smb-agent over to a single-process model instead of fork()
in order to reuse client connections. except, of course, you
can't do a select() on the same socket connections! argh!
(This used to be commit e9e5a34de8)
ideas from ssh-agent.
the intent is to be able to share smb sessions using cli_net_use_add()
across multiple processes, where one process knows the target server
name, user name and domain, but not the smb password.
(This used to be commit 294b653f2e)
lp_trusted_domains() parameter, so trusted domain logins should work,
right, if you put user = TRUSTED_DOMAIN\NTuser in "domain name map", right?
right - as _long_ as you're not using NTLMv2, because the damn NT username
gets mapped to the damn unix name too early, and NTLMv2 challenge-responses
are based on the client's user name, client's domain name, client's host name
etc damn etc.
so it becomes necessary to stop using char* username because this allows
for massive amounts of confusion as to which username is being referred to.
the underlying unix username on the local unix system that is associated with
the smbd process that represents the NT username? or the NT username itself?
(This used to be commit dd3ccdd7d9)
from previous lsaquery command. over-ridden from DOMAIN\username
2) initialisation of cli_state is a little more specific: sets use_ntlmv2
to Auto. this can always be over-ridden.
3) fixed reusage of ntlmssp_cli_flgs which was being a pain
4) added pwd_compare() function then fixed bug in cli_use where NULL
domain name was making connections multiply unfruitfully
5) type-casting of mallocs and Reallocs that cause ansi-c compilers to bitch
(This used to be commit 301a6efaf6)
verified that lsaquery, lsalookupsids work, and found some bugs in the
parameters of these commands :-)
soo... we now have an lsa_* api that has the same arguments as the nt
Lsa* api! cool!
the only significant coding difference is the introduction of a
user_credentials structure, containing user, domain, pass and ntlmssp
flags.
(This used to be commit 57bff6fe82)
msrpc client code. the intent is to hide / abstract / associate
connection info behind policy handles.
this makes the msrpc functions look more and more like their nt equivalents.
who-hou!
(This used to be commit c01b18e632)
have we got. and what data do we have. hmm.. i wonder what the NTLMv2
user session key can be... hmmm... weell.... there's some hidden data
here, generated from the user password that doesn't go over-the-wire,
so that's _got_ to be involved. and... that bit of data took a lot of
computation to produce, so it's probably _also_ involved... and md4 no, md5?
no, how about hmac_md5 yes let's try that one (the other's didn't work)
oh goodie, it worked!
i love it when this sort of thing happens. took all of fifteen minutes to
guess it. tried concatenating client and server challenges. tried
concatenating _random_ bits of client and server challenges. tried
md5 of the above. tried hmac_md5 of the above. eventually, it boils down
to this:
kr = MD4(NT#,username,domainname)
hmacntchal=hmac_md5(kr, nt server challenge)
sess_key = hmac_md5(kr, hmacntchal);
(This used to be commit ab174759cd)
implementation (NT5) when you discover that your code is trash.
samr_enum_dom_users(), samr_enum_dom_aliases() and samr_enum_dom_groups()
all take a HANDLE for multiple-call enumeration purposes.
(This used to be commit 19490d8b4f)
this format is what i would like _all_ these functions to be
(returning status codes, not BOOL) but that's a horrendous
amount of work at the moment :)
(This used to be commit 02f2406042)
a problem i was having.
- added rudimentary CAP_STATUS32 support for same reason.
- added hard-coded, copy-the-same-data-from-over-the-wire version of
CAP_EXTENDED_SECURITY, which is a security-blob to encapsulate
GSSAPI which encodes
SPNEGO which is used to negotiate
Kerberos or NTLMSSP. i have implemented
NTLMSSP which negotiates
NTLMv1 or NTLMv2 and 40-bit or 128-bit etc. i have implemented
NTLMv1 / 40-bit.
*whew*.
(This used to be commit e5b80bd2f7)
