On Thu, 2003-01-02 at 18:00, [EMAIL PROTECTED] 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.
>
> So if unix extensions are "true", th
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.
So if unix extensions are "true", then all opens set O_NOFOLLOW.
Ok if O_NOFOLLOW is defined and exist
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, w
[EMAIL PROTECTED] 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 s
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 s
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 y
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
On Tue, 2002-12-31 at 20:36, Simo Sorce wrote:
> On Tue, 2002-12-31 at 03:29, [EMAIL PROTECTED] wrote:
> > Sorry, I have some problems with this patch. It allows a
> > client to add a symlink to a Samba share which points to
> > a file elsewhere on the server disk. For example :
> >
> > create a s
On Tue, 2002-12-31 at 03:29, [EMAIL PROTECTED] wrote:
> Sorry, I have some problems with this patch. It allows a
> client to add a symlink to a Samba share which points to
> a file elsewhere on the server disk. For example :
>
> create a symlink from /home/myhome/p -> /etc/passwd.
>
> Now as Samb
On Fri, Dec 27, 2002 at 07:09:43PM +1100, John Newbigin wrote:
> If no one has any problems with this patch, can it be applied?
>
> John.
>
> Original Message ----
> Subject: Patch for unix extensions
> Date: Tue, 03 Dec 2002 09:51:39 +1100
> From: John Ne
If no one has any problems with this patch, can it be applied?
John.
Original Message
Subject: Patch for unix extensions
Date: Tue, 03 Dec 2002 09:51:39 +1100
From: John Newbigin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
This is a small patch which added a new config opt
>This is a small patch which added a new config option to turn the
>ensure_link_is_safe check off.
The link check for symlinks also incorrectly parses relative target paths
as relative to the root of the share name rather than relative to the
directory containing the symbolic link file.So
This is a small patch which added a new config option to turn the
ensure_link_is_safe check off. This check prevents a client using the
unix extensions from creating a symlink which points to a directory
outside of the share. Many GUI programs make links from ~ to /tmp which
will fail. Gnom
13 matches
Mail list logo
