headers
Brad Hards | 1 May 2008 12:32

Question on lp_load() and smb_iconv_open()

source/param/loadparm.c, line 2477 (in lp_load()) calls smb_iconv_open() (in 
lib/charset/iconv.c). That ends up calling the system iconv_open().

There is a smb_iconv_close() function (which calls the system iconv_close()) 
to clean up. However loadparm.c doesn't appear to call it. It doesn't even 
store the 

I'm not sure how to fix this. The easiest way would appear to be some kind of 
lp_unload() that gets the smb_iconv_t back from the lib/util/dprintf.c static 
variable, and then calls smb_iconv_close().

Comments, suggestions, or patches most welcome...

Brd
Permalink | Reply | 4 comments |
headers
Alexander Bokovoy | 1 May 2008 13:03
Picon
Favicon
Gravatar

Re: Question on lp_load() and smb_iconv_open()

2008/5/1, Brad Hards <bradh <at> frogmouth.net>:
> source/param/loadparm.c, line 2477 (in lp_load()) calls smb_iconv_open() (in
>  lib/charset/iconv.c). That ends up calling the system iconv_open().
>
>  There is a smb_iconv_close() function (which calls the system iconv_close())
>  to clean up. However loadparm.c doesn't appear to call it. It doesn't even
>  store the
>
>  I'm not sure how to fix this. The easiest way would appear to be some kind of
>  lp_unload() that gets the smb_iconv_t back from the lib/util/dprintf.c static
>  variable, and then calls smb_iconv_close().
>
>  Comments, suggestions, or patches most welcome...
What about allocating it on some global context and set destructor to
that structure to call smb_iconv_close()? This way it will be closed
automatically when global context is destroyed.
--

-- 
/ Alexander Bokovoy
Permalink | Reply | 3 comments |
headers
Ralph Böhme | 1 May 2008 13:27
Picon

Re: VFS to NTFS transition


Am 28.04.2008 um 18:35 schrieb James Peach:
>> All operations by either Mac or Windows clients (e.g. rename,  
>> delete etc.) shall be performed well on basis of the current  
>> netatalk adouble:v2 implementation. Most importantly vfs_netatalk  
>> must copy and move adouble:v2 files upon SMB copy/move actions.
>>
>> This and any further anhancemnet is done with the following  
>> assumptions in mind:
>> - primary filing protocol for Macs is AFP -- CIFS for Macs is  
>> considered a bad idea in this setup
>> - it is unecessary that SMB clients access Mac metadata or  
>> ressource forks (as you are doing -- which applications actually  
>> make use of that?)
>
> These two assumptions are bogus.

Maybe, maybe not. They're defining the engineering focus: limited but  
well defined and and lastly this is vfs_netatalk we're talking about.

> The 10.5 smbfs client does natively propagate Mac metadata and  
> resource forks across SMB. It provides a user experience that is  
> virtually indistinguishable from AFP.

Yeah, I know. And that relies on a server side implementation that  
must store the extra data $somewhere. Later on we can go on enhance  
this and implement a more complete solution probably on basis of  
adouble:sfm and vfs_ads:

Am 24.04.2008 um 15:03 schrieb Shlomi Yaakobovich:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jelmer Vernooij | 1 May 2008 13:42
Picon
Favicon

Re: Question on lp_load() and smb_iconv_open()

On Thu, 2008-05-01 at 15:03 +0400, Alexander Bokovoy wrote:
> 2008/5/1, Brad Hards <bradh <at> frogmouth.net>:
> > source/param/loadparm.c, line 2477 (in lp_load()) calls smb_iconv_open() (in
> >  lib/charset/iconv.c). That ends up calling the system iconv_open().
> >
> >  There is a smb_iconv_close() function (which calls the system iconv_close())
> >  to clean up. However loadparm.c doesn't appear to call it. It doesn't even
> >  store the
> >
> >  I'm not sure how to fix this. The easiest way would appear to be some kind of
> >  lp_unload() that gets the smb_iconv_t back from the lib/util/dprintf.c static
> >  variable, and then calls smb_iconv_close().
> >
> >  Comments, suggestions, or patches most welcome...
> What about allocating it on some global context and set destructor to
> that structure to call smb_iconv_close()? This way it will be closed
> automatically when global context is destroyed.
This is the iconv handle used by DEBUG. Deallocating it could have
strange side-effects.. Ideally, lp_load() should not be touching any
global state. 

Generally, an application should only be calling lp_load() once and the
iconv context set then will live until the end of the process. Is there
a particular reason this variable is a problem atm?

Cheers,

Jelmer

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brad Hards | 1 May 2008 13:59

Re: Question on lp_load() and smb_iconv_open()

On Thursday 01 May 2008 09:42:24 pm Jelmer Vernooij wrote:
> On Thu, 2008-05-01 at 15:03 +0400, Alexander Bokovoy wrote:
> > 2008/5/1, Brad Hards <bradh <at> frogmouth.net>:
> > > source/param/loadparm.c, line 2477 (in lp_load()) calls
> > > smb_iconv_open() (in lib/charset/iconv.c). That ends up calling the
> > > system iconv_open().
> > >
> > >  There is a smb_iconv_close() function (which calls the system
> > > iconv_close()) to clean up. However loadparm.c doesn't appear to call
> > > it. It doesn't even store the
> > >
> > >  I'm not sure how to fix this. The easiest way would appear to be some
> > > kind of lp_unload() that gets the smb_iconv_t back from the
> > > lib/util/dprintf.c static variable, and then calls smb_iconv_close().
> > >
> > >  Comments, suggestions, or patches most welcome...
> >
> > What about allocating it on some global context and set destructor to
> > that structure to call smb_iconv_close()? This way it will be closed
> > automatically when global context is destroyed.
>
> This is the iconv handle used by DEBUG. Deallocating it could have
> strange side-effects.. Ideally, lp_load() should not be touching any
> global state.
>
> Generally, an application should only be calling lp_load() once and the
> iconv context set then will live until the end of the process. Is there
> a particular reason this variable is a problem atm?
It isn't really a problem, just an annoyance in the "still reachable" valgrind
output. On my machine, it is ~32K across four "loss records".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gerald (Jerry) Carter | 1 May 2008 18:56
Picon
Favicon

http://news.samba.org/


Folks,

I've posted a description of a couple of volunteer (non-developer)
positions we are trying to fill.  I'll repost here for efficiency.
I'm hoping to find two people to help out.

cheers, jerry

===================
The Samba Team is looking for people to help keep our user
community information current, covering development news,
releases, general news, and events. The scope of the
positions will be to:

    * Gather stories, summaries, and content for the
      bi-weekly Samba Mashup Report (community newsletter)
    * Work on the active content at http://news.samba.org/

We are looking initially for two volunteers to help us. If
you are interested in helping, please send a short mail to
web-editor <at> samba.org describing why you think you would be a
good match.
===================
Permalink | Reply | 0 comments |
headers
miguel.sanders | 1 May 2008 18:57

Sid S-0-0 is not in a valid format: Samba 3.0.28

Guy

I am currently running 3.0.28 and even though everything works fine, the logs keep mentioning

[2008/04/26 05:04:37, 0] lib/util_sid.c:string_to_sid(242)
  string_to_sid: Sid S-0-0 is not in a valid format.

Many many times.

Could anyone explain what cuases this?

Thnx!

Met vriendelijke groet
Best regards
Bien à vous

Miguel SANDERS
ArcelorMittal Gent

UNIX System Administrator | SAP Infrastructure Group
John Kennedylaan 51, B-9042 Gent

T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders <at> arcelormittal.com
www.arcelormittal.com/gent
Permalink | Reply | 2 comments |
headers
Gerald (Jerry) Carter | 1 May 2008 19:04
Picon
Favicon

Re: Sid S-0-0 is not in a valid format: Samba 3.0.28


miguel.sanders <at> arcelormittal.com wrote:
> Guy
> 
> I am currently running 3.0.28 and even though everything works fine, the logs keep mentioning
> 
> [2008/04/26 05:04:37, 0] lib/util_sid.c:string_to_sid(242)
>   string_to_sid: Sid S-0-0 is not in a valid format.
> 
> Many many times.
> 
> Could anyone explain what cuases this?

I expect somewhere we are trying to convert a NULL SID to a
string and back again.

cheers, jerry
--
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
Permalink | Reply | 0 comments |
headers
yaberger | 1 May 2008 21:50
Picon

Samba 3.0 / 3.2 heap overflow on AIX?

Hi,

I'm trying to find a possible heap overflow which first seemed to be in 
AIX 5.3 with Samba (3.0 ou 3.2).
With the AIX support, we've been able to use some debugging utility, debug 
libc, etc. on AIX that allow the support to think the problem might be in 
Samba code

Actually, without any modification to Samba code and using a local (AIX) 
userid, Samba is working #1.
But when I add a few lines to allow AIX authentication on using the LAM 
(Loadable Authentication Module) and authenticating with a DCE userid 
belonging to more than 32 groups, it coredump.
The same patch/tests is working #1 without this problem on AIX 5.2 btw.
Before telling me that the problem might come from my patch or the DCE 
client or AIX, please take the time to read what's below

With this scenario, Samba was coredumping when I was doing the 
connection/authentication from a windows workstation with the DCE userid 
(belonging to more than DCE groups). By looking at the stack/traces of the 
core file, it pointed me that it was coredumping in initgroups(), which is 
an OS syscall. By replacing the AIX syscall with the rep_initgroups() 
you're providing to system without an initgroups() implementation, I'm 
able to authenticate with this user correctly (no coredump)

I've opened a PMR (Problem Management Request) to the AIX team because I 
thought the overflow was in initgroups() or a subroutine called by it 
which wasn't in debug mode. After some collaboration with them, we've 
ended with the following 2 tests that let us think the heap overflow might 
be in Samba and possibly in rbtree.c (explaination in the test below).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Volker Lendecke | 1 May 2008 23:21
Picon
Favicon

Re: Samba 3.0 / 3.2 heap overflow on AIX?

On Thu, May 01, 2008 at 03:50:57PM -0400, yaberger <at> ca.ibm.com wrote:
> I'm trying to find a possible heap overflow which first seemed to be in 
> AIX 5.3 with Samba (3.0 ou 3.2).
> With the AIX support, we've been able to use some debugging utility, debug 
> libc, etc. on AIX that allow the support to think the problem might be in 
> Samba code

rbtree.c is new in 3.2, it's from the Linux kernel. It might
well be that the AIX compiler does not like it, it uses some
pointer tricks. I would guess that the AIX compiler in that
strict mode would not allow C code to set a pointer to a
non-aligned value at all, and that this raises the
exception. rbtree.c however is quite careful to strip those
bits again before the pointer is actually dereferenced.

We might have to modify the code for these special compiler
settings if they are of general, wider use in production
systems.

But you said that you also get it with 3.0 which does not
have this new code. Can you try to do the same analysis
there?

Thanks,

Volker
Permalink | Reply | 1 comment |

Gmane