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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
on the glibc source code and are safer than the traditional popen as
they don't use a shell to exec the requested command. Now we have
these functions they can be tightened up (environment etc.) as required
to make a safe popen. It should now be safe to add the environement
variable loading code to loadparm.c
Jeremy.
two places i found where it was appropriate to _use_ that third argument,
in locking.c and brlock.c! there was a static traverse_function and
i removed the static variable, typecast it to a void*, passed it to
tdb_traverse and re-cast it back to the traverse_function inside the
tdb_traverse function. this makes the use of tdb_traverse() reentrant,
which is never going to happen, i know, i just don't like to see
statics lying about when there's no need for them.
as i had to do in samba-tng, all uses of tdb_traverse modified to take
the new void* state argument.
2) disabled rpcclient: referring people to use SAMBA_TNG rpcclient.
i don't know how the other samba team members would react if i deleted
rpcclient from cvs main. damn, that code's so old, it's unreal.
20 rpcclient commands, instead of about 70 in SAMBA_TNG.
note the ugly global_smbpid - I hope that won't bethere for long, I
just didn't want to do two lots of major surgery at the one time.
Using global_smbpid avoids the big change of getting rid of our
inbuf/outbuf interface to reply routines. I'll do that once the
locking stuff passes all tests.
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
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 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 means "nmblookup -S" now always works, even with broken servers
the database stores all unexpected replies and these can be accessed
by any client.
while doing this I cleaned up a couple of functions, and put in place
a better trn_id generator. in most places the code got quite a bit
simpler due to the addition of simple helper functions.
I haven't yet put the code in to take advantage of this for pdc
replies - that will be next. Jeremys pdc finding code will then work :)
- added TDB_CLEAR_IF_FIRST flag to clear the database if this is the
first attached process. Useful for non-persistent databases like our
locking area (this will also make upgrades to new database layouts easier)
- use lock_path() in a couple of places
- leave connections database open while smbd running
- cleaned up some tdb code a little, using macros for constants
instead of either sysv or mmap shared memory or lock files.
this means we can now completely remove
locking_shm.c
locking_slow.c
shmem.c
shmem_sysv.c
and lots of other things also got simpler
locking.c got a bit larger, but is much better compartmentalised now
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.
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
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.
received properly when a UDP "retry" occurs. it's because reads and
writes must be interleaved / matched.
scenario:
nmblookup connects to agent, sends request.
agent receives request, broadcasts it on 137.
agent RECEIVES 137 broadcast, sends it to nmblookup
agent receives RESPONSE to 137 broadcast, sends it to nmblookup.
if reads are not equally interspersed with writes, then second send
will fail.
if you think this is odd behaviour and that the agent should be filtering
its own UDP traffic, think again.
agent will be, potentially, redirecting nmbd traffic (including WINS
server) not just client programs.
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).
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!
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.
