Age | Commit message (Collapse) | Author | Files | Lines |
|
Michael
|
|
|
|
Often times before creating a file, a client will first query to see
if it already exists. Since some systems have a case-insensitive stat
that is called from unix_convert, we can definitively return
STATUS_NO_SUCH_FILE to the client without scanning the whole
directory.
This code path is taken from trans2querypathinfo, but trans2findfirst
still does a full directory scan even though the get_real_filename
(the case-insensitive stat vfs call) can prevent this.
This patch adds the get_real_filename call to the trans2find* path,
and also changes the vfs_default behavior for
SMB_VFS_GET_REAL_FILENAME. Previously, in the absence of a
get_real_filename implementation, we would fallback to the full
directory scan. The default behavior now returns -1 and sets errno to
EOPNOTSUPP. This allows SMB_VFS_GET_REALFILENAME to be called from
trans2* and unix_convert.
|
|
Jeremy.
|
|
|
|
Addendum to c49730e1. Use newer cookie conversion names.
|
|
|
|
context.
Guenther
|
|
talloc_free on malloced memory.
Guenther
|
|
Guenther
|
|
Michael
|
|
|
|
Patch from Blindauer Emmanuel <samba@mooby.net>.
Guenther
|
|
Jeremy.
|
|
Jeremy.
|
|
This bug prompted several, fairly large changes to the of OneFS's
readdirplus() within Samba.
One fundamental problem is that we kept our cache cursor pointed at the
next entry to be returned from onefs_readdir(), while the resume cookie
needed to refill the cache such that our cursor would be on this entry,
was located in the previous cache entry. This meant that to correctly handle
seekdir() cases which could be found within the existing cache, and cases
where a cache reload was needed, required that the cache always hold
at least two entries: the entry we wished to return, and the previous entry
which held the resume cookie. Since the readdirplus() syscall gives us no
guarantee that it will always return these two direntries, there was a
fundamental problem with this design.
To fix this problem, I have rearchitected the onefs_readdir() path to keep
its pointer on the entry which contains the resume_cookie, not the entry
which will be returned next. Essentially, I changed onefs_readdir() from a
"return an entry then increment the cursor" model to "increment the cursor
then return an entry". By doing this, we only require that a single entry
be within the cache: the entry containing the resume cookie.
Second, there have been numerous off-by-one bugs in my implementation of
onefs_seekdir() which did a mapping between the 64-bit resume cookie
returned by readdirplus() and its own monotonically increasing "location"
offset. Furthermore, this design caused a somewhat frequent waste of
cycles, as in some cases we'd need to re-enumerate the entire directory to
recover the current "location" from an old resume cookie. As this code was
somewhat difficult to understand, prone to bugs, and innefficient in some
cases I decided it was better to wholesale replace it now, rather than later.
It is possible to algorithmically map the 64-bit resume cookies from
readdirplus() into 32-bit offset values which SMB requires. The onefs.so
module now calls into a system library to do this conversion. This greatly
simplifies both the seekdir() and telldir() paths and is more efficient.
|
|
|
|
|
|
Jeremy.
|
|
event.
Shows that doing a tdis with invalid uid succeeds.
Jeremy.
|
|
|
|
|
|
The underlying problem
is that once SMBulogoff is called, all server_info contexts associated with the
vuid should become invalid, even if that's the context being currently used by
the connection struct (tid). When the SMBtdis comes in it doesn't need a valid
vuid value, but the code called inside vfs_full_audit always assumes that there
is one (and hence a valid conn->server_info pointer) available.
This is actually a bug inside the vfs_full_audit and other code inside Samba,
which should only indirect conn->server_info on calls which require AS_USER to
be set in our process table. I could fix all these issues, but there's no
guarentee that someone might not add more code that fails this assumption, as
it's a hard assumption to break (it's usually true).
So what I've done is to ensure that on SMBulogoff the previously used
conn->server_info struct is kept around to be used for print debugging purposes
(it won't be used to change to an invalid user context, as such calls need
AS_USER set). This isn't strictly correct, as there's no association with the
(now invalid) context being freed and the call that causes conn->server_info to
be indirected, but it's good enough for most cases.
The hard part was to ensure that once a valid context is used again (via new
sessionsetupX calls, or new calls on a still valid vuid on this tid) that we
don't leak memory by simply replacing the stored conn->server_info pointer. We
would never actually leak the memory (as all conn->server_info pointers are
talloc children of conn), but with the previous patch a malicious client could
cause many server_info structs to be talloced by the right combination of SMB
calls. This new patch introduces free_conn_server_info_if_unused(), which
protects against the above.
Jeremy.
|
|
This should fiy bug #5853. Thanks to D.L. Meyer <dlmeyer [at] uiuc.edu>
for reporting.
Karolin
|
|
Karolin
|
|
|
|
I don't think we should unconditionally send every refused connection attempt
to a share to syslog, that's where all debug level 0 messages end up.
|
|
We need to allow to set filesystem capabilities from the default vfs in
create_conn_struct() in order to find mixed-case filenames. Thanks Volker!
This one was hard to find, so a little longer explanation:
When a Windows client tries to upload e.g. the Xerox 4110 PS driver, the client
first uploads the driver files to the [print$] share. Some of them (in this case
the Windows Postscript drivers) are with uppercase filenames while some of them
(like the PPD file) are in lowercase. After the driver upload the client issues
the spoolss_AddPrinterDriverEx() call with level 6. There the client tries to
add the PPD file with an uppercase filename (while having stored it in lowercase
on the server). The internal spoolss add driver functions then could not find the
appropriate filename while trying to move them to the version subdirectory (in
this case W32X86/3) and fails then entire spoolss_AddPrinterDriverEx() call.
With this fix, the convert_unix_name() name finds the correct file and
the spoolss_AddPrinterDriverEx() succeeds.
Guenther
|
|
|
|
|
|
|
|
|
|
Haven't checked this myself, but as I've already got several reports that Samba
won't compile against current OpenAFS anymore, I just believe Geza Gemes. This
patch only affects AFS code, so it should not hurt anything else.
Volker
|
|
|
|
That fixes bug #4247. Thanks to David McNeill <davemc [at] mcpond.co.nz>
for reporting!
Karolin
|
|
This fixes bug #4245. Thanks to David McNeill <davemc [at] mcpond.co.nz>
for reporting!
Karolin
|
|
|
|
cc: "../librpc/ndr/ndr_basic.c", line 572: warning 604: Pointers are not assignment-compatible.
Apparently in_addr.s_addr is not compatible to uint32_t, maybe a 32-bit signed
int.
|
|
That compiler does not like #if embedded into the macro NT_STATUS_IS_OK.
|
|
No idea why it works on my Linux without -lpthread ... :-)
|
|
|
|
Python.h 2.5 on that platform does not #include the necessary headers
to see uintptr_t.
|
|
|
|
|
|
|
|
|
|
given that the number of image formats we use is limited.
|
|
and one of the reasons the complex dependency system exists.
|
|
|
|
|