headers
Andrew Bartlett | 1 Jan 2003 01:29
Picon
Favicon

Re: smbstatus -b in a 100% NT environment

On Mon, 2002-12-16 at 23:17, Guillaume LACHENAL wrote:
> Is there way to obtain the same result thant 'smbstatus -b'
> (ie knowing who is logged in which computer) when the PDC
> is a not a Samba one ?
> 
> Is there a way to request this type of query on a NT PDC ?
> (third party {linux|win32} tools / urls welcomed)

Server manager on NT will show you that - I don't think Samba has a
remote client for that at present, but it would not be particularly hard
to write.

> Or is there another way to do it via network sniffing ?
> 
> thanks a lot !
> 
> regards,
> 
> Guillaume
--

-- 
Andrew Bartlett                                 abartlet <at> pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet <at> samba.org
Student Network Administrator, Hawker College   abartlet <at> hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
Permalink | Reply | 0 comments |
headers
Simo Sorce | 1 Jan 2003 13:01
Picon
Favicon

Re: Patch for unix extensions

My idea was this:
let make it so taht if unix extensions are enabled, then we NEVER
resolve the links if we permit link creation.
If we do not want to have it so rigid, we may also add a proper option,
something like "wide unix symlinks" with all the proper warnings and
normally disabled. Then if you do a normal call, the link will be
honoured only if inside the exported file system.

This way the trick cannot work, and unix applications (or setups) that
rely on symlinks to work well are happy.

Simo.

On Tue, 2002-12-31 at 20:48, jra <at> dp.samba.org wrote:
> On Tue, Dec 31, 2002 at 10:36:33AM +0100, Simo Sorce wrote:
> > 
> > Jeremy,
> > in case of unix extensions, shouldn't we pass the symlink as is and not
> > resolve it?
> 
> Yes we do - if the client uses the UNIX extensions to
> readlink. The problem is a UNIX extension client could
> set a symlink on the server (which in a UNIX <--> UNIX
> scenario would never be resolved on the server, but read
> and resolved on the clients filesystem) and then do a
> normal SMB open call on it to escape the restrictions
> of exporting only a small part of the servers filesystem.
> 
> > I think a proper unix-like file system should be able to return links.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Sharpe | 1 Jan 2003 21:09

Feedback on samba profiles util (fwd)


---------- Forwarded message ----------
Date: Wed, 01 Jan 2003 03:36:19 -0600 (CST)
From: lelie <at> airmail.net
To: rsharpe <at> richardsharpe.com
Subject: samba profiles util

hey guy, i just want to thank you for the profiles util in samba.
it saved my life.  i had to modify a bunch of terminal server roamining
profiles because i had to move the servers from one domain to another.

----------------------------------------

Regards
-----
Richard Sharpe, www.richardsharpe.com, rsharpe[at}richardsharpe{dot]com
Permalink | Reply | 0 comments |
headers
Steve Langasek | 1 Jan 2003 21:35
Favicon

Re: Patch for unix extensions

On Wed, Jan 01, 2003 at 01:01:19PM +0100, Simo Sorce wrote:
> My idea was this:
> let make it so taht if unix extensions are enabled, then we NEVER
> resolve the links if we permit link creation.
> If we do not want to have it so rigid, we may also add a proper option,
> something like "wide unix symlinks" with all the proper warnings and
> normally disabled. Then if you do a normal call, the link will be
> honoured only if inside the exported file system.

> This way the trick cannot work, and unix applications (or setups) that
> rely on symlinks to work well are happy.

If symlinks will never be resolved outside of the exported share, why do
you need to resolve them on the server at all?  A Unix client is equally
capable of resolving this symlink on the server.

--

-- 
Steve Langasek
postmodern programmer
Permalink | Reply | 1 comment |
headers
John Newbigin | 1 Jan 2003 23:17
Picon
Picon

Re: Patch for unix extensions

jra <at> dp.samba.org wrote:
> On Tue, Dec 31, 2002 at 10:36:33AM +0100, Simo Sorce wrote:
> 
>> Jeremy, in case of unix extensions, shouldn't we pass the symlink
>> as is and not resolve it?
> 
> 
> Yes we do - if the client uses the UNIX extensions to readlink. The
> problem is a UNIX extension client could set a symlink on the server
> (which in a UNIX <--> UNIX scenario would never be resolved on the
> server, but read and resolved on the clients filesystem) and then do
> a normal SMB open call on it to escape the restrictions of exporting
> only a small part of the servers filesystem.
This is not always a problem.  There might be cases where users must be
restricted to a specific shared directory, but in the case of UNIX
extensions, the users probably* have shell access to the server anyway.
  Using samba they still have the same user restrictions as shell access
so there is no greater security risk if they access a file remotly than
if they do localy.

By making this an option, the default level of security is suitable for
a restricted server but can be relaxed if need be.  The name of this
option could be changed and perhaps other semantics associated with it
(what exactly is a wide link?) but I don't think it creates any
security problems.

John.

*probably is a bit of a generalisation.  In the case of sharing home 
directories it is possible.  What other writable directories are going
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Sharpe | 2 Jan 2003 05:52

At least some people appreciate the effort we put in

Hi,

Last Sunday I saw an email in the samba-technical mailing list from 
someone who complained that a certain feature of smbclient/smbtar did not 
work. Specifically, he had complained the week before that files larger 
than 4GB were not being handled properly when backed up from a Windows 
system. Herb Lewis worked on it and provided some patches. Then, on 
Sunday, he complained again that while the patches worked for getting 
files, but in putting a 4+GB file to a Windows system failed.

So, despite having other things to do and having a family etc, I spent 
time duplicating the problem, tracked the issues down and fixed it, and 
then tested that the files were transferred without corruption. Moving and 
comparing a 5GB file with a copy takes a while :-(

Then I supplied the patches to the person who complained and made sure 
they were applied to two of the three branches of Samba that we care 
about, and would have applied it to the third branch if Jeremy hadn't 
beat me to it.

However, I was staggered when several days went by and I received no feed 
back from the person who complained. Certainly no thankyou, but not even 
something to say that the patches worked or didn't.

However, last night, within seconds of midnight, I got this from someone 
else.

>Date: Wed, 01 Jan 2003 03:36:19 -0600 (CST)
>From: lelie <at> airmail.net
>To: rsharpe <at> richardsharpe.com
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simo Sorce | 2 Jan 2003 10:16
Picon
Favicon

Re: Patch for unix extensions

On Wed, 2003-01-01 at 21:35, Steve Langasek wrote:
> On Wed, Jan 01, 2003 at 01:01:19PM +0100, Simo Sorce wrote:
> > My idea was this:
> > let make it so taht if unix extensions are enabled, then we NEVER
> > resolve the links if we permit link creation.
> > If we do not want to have it so rigid, we may also add a proper option,
> > something like "wide unix symlinks" with all the proper warnings and
> > normally disabled. Then if you do a normal call, the link will be
> > honoured only if inside the exported file system.
> 
> > This way the trick cannot work, and unix applications (or setups) that
> > rely on symlinks to work well are happy.
> 
> If symlinks will never be resolved outside of the exported share, why do
> you need to resolve them on the server at all?  A Unix client is equally
> capable of resolving this symlink on the server.

They ARE resolved for normal CIFS clients that does not ask for UNIX
extensions.

--

-- 
Simo Sorce    -  idra <at> samba.org
Samba Team    -  http://www.samba.org
Italian Site  -  http://samba.xsec.it
Permalink | Reply | 0 comments |
headers
Stefan (metze) Metzmacher | 2 Jan 2003 13:51
Picon

Re: [PATCH] parametric options

At 09:07 01.01.2003 +1100, Andrew Bartlett wrote:
>On Wed, 2003-01-01 at 02:44, Stefan (metze) Metzmacher wrote:
> > Hi *,
> >
> > here are the parametric option changes of my big patch...
> >
> > all lp_param_*() functions now take the default value as last parameter
> > this is usefull for all fn's and needed for the enum,bool,int and ulong
> > functions :-)
>
>Is this the best way to do it - if we are going to have a notion of
>defaults, then doing it per-call is just waiting for disaster!  Given
>that we are moving to a 'registration' style of module system (where we
>know at startup what modules we have), I think we really should move
>'parametric options' to a registrations system too.  Indeed, this would
>allow the implement ion of callback syntax checking, which could make
>testparm useful again.

sounds good :-) but I don't know how to handle this when a vfs modules are 
loaded in a per share configuration... (it's easier to discuss details on 
IRC :-)

> > lp_parm_string_list() now use talloc_str_list_make() and
> > talloc_realloc_str_list_make and caches the the result for the called
> > seperator, so if the function is called with the same separator it is not
> > needed to call *_str_list_make()
> >
> > if the function is called with an other separator the old list is free'ed
> >
> > so we didn't get a memory leek if we call:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Bartlett | 2 Jan 2003 14:10
Picon
Favicon

Re: [PATCH] parametric options

On Thu, 2003-01-02 at 23:51, Stefan (metze) Metzmacher wrote:

> >This doesn't seem right - why not just free and replace that talloc
> >context?
> 
> I only want to free one segment in the talloc context and all other 
> talloced memory in this talloc context should not be free'ed!
> 
> > > a also add a view talloc_realloc_*() functions
> > >
> > > talloc_realloc_strdup() ...
> >
> >Why?
> 
> If we have a struct witch is talloced
> and strings in the struct are talloced on the same talloc context should be 
> replaced, it would be fine to free the memory of the old string...:-)

Talloc doesn't work that way, and should not be made to work that way. 
If you want that, then you have malloc() and free().

Andrew Bartlett

--

-- 
Andrew Bartlett                                 abartlet <at> pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet <at> samba.org
Student Network Administrator, Hawker College   abartlet <at> hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
Permalink | Reply | 0 comments |
headers
Stefan (metze) Metzmacher | 2 Jan 2003 14:26
Picon

Re: [PATCH] parametric options

At 00:10 03.01.2003 +1100, Andrew Bartlett wrote:

>*** PGP Signature Status: good
>*** Signer: Andrew Francis Bartlett <abartlet <at> pcug.org.au> (Invalid)
>*** Signed: 02.01.2003 14:10:23
>*** Verified: 02.01.2003 14:22:37
>*** BEGIN PGP VERIFIED MESSAGE ***
>
>On Thu, 2003-01-02 at 23:51, Stefan (metze) Metzmacher wrote:
>
> > >This doesn't seem right - why not just free and replace that talloc
> > >context?
> >
> > I only want to free one segment in the talloc context and all other
> > talloced memory in this talloc context should not be free'ed!
> >
> > > > a also add a view talloc_realloc_*() functions
> > > >
> > > > talloc_realloc_strdup() ...
> > >
> > >Why?
> >
> > If we have a struct witch is talloced
> > and strings in the struct are talloced on the same talloc context 
> should be
> > replaced, it would be fine to free the memory of the old string...:-)
>
>Talloc doesn't work that way, and should not be made to work that way.
>If you want that, then you have malloc() and free().
(Continue reading)

Permalink | Reply | 1 comment |

Gmane