[Samba] SOLVED Symlink outside the share path

Kathy banshee135 at gmail.com
Wed Aug 20 12:58:03 MDT 2014


Okay, this problem is solved.

It turns out when I was doing the wide links and unix extensions option it
really was working.  It wasn't until I logged out and logged back in to the
client to get a fresh smb connection that it worked.

So I'm good.  Thanks for the help everyone.  I appreciate it.

Kathy



On Wed, Aug 20, 2014 at 11:28 AM, Kathy <banshee135 at gmail.com> wrote:

> Yes, already have.  "wide links = yes" (or no, which is the default) is
> the correct one according to manpage, but when I tried that one last night,
> it doesn't work.  Smbd takes the option okay and doesn't complain, but it's
> like it doesn't pay attention to the option.  I have tried it in different
> combos with unix extensions set on and off and in both the global and the
> share definitions.  Follow symlinks is always on.  So I think the issue is
> not that I'm using the wrong syntax, it's that it ignores it and still
> denies access outside the shared filesystem.
>
> This is what I've seen others complain of when searching on Google.  That
> they use these options in smb.conf, but after reload the server still
> ignores them.
>
>
> On Wed, Aug 20, 2014 at 10:58 AM, Taylor, Jonn <jonnt at taylortelephone.com>
> wrote:
>
>>  "man smb.conf" for correct syntax
>>
>>
>>   On 08/20/2014 12:27 PM, Kathy wrote:
>>
>>  Hi John --
>>
>>  It doesn't seem to like "wide links" or "wide symlinks".
>>
>>  [2014/08/20 10:10:56, 0] param/loadparm.c:map_parameter(2794)
>>   Unknown parameter encountered: "wide symlinks"
>>
>>  I have confirmed that on an old Samba server of mine on an old machine
>> (Samba 3.0.5), I can do this just fine.  But on any of the newer Redhat
>> Linux distros I can't and none of these options are working.  Has anyone
>> running RHEL 5.X or 6.X gotten this to work to bypass the security on
>> symlinks?
>>
>>  Thanks --
>>
>>  Kathy
>>
>>
>> On Wed, Aug 20, 2014 at 9:54 AM, Taylor, Jonn <jonnt at taylortelephone.com>
>> wrote:
>>
>>> Try this.
>>>
>>> follow symlinks = yes
>>> wide symlinks = yes
>>> unix extensions = no #if needed
>>>
>>>
>>> On 08/19/2014 09:39 PM, Kathy wrote:
>>> > Hi Achim --
>>> >
>>> > Boy, that sounds like what I need.  Although I'm getting this when
>>> Samba
>>> > tries reloading smb.conf:
>>> >
>>> > [2014/08/19 19:31:30, 0] param/loadparm.c:map_parameter(2794)
>>> >   Unknown parameter encountered: "allow insecure wide links"
>>> >
>>> > This is Samba Version 3.0.33-3.40.el5_10 through Redhat RPM.  Makes me
>>> > think that isn't part of this distro.
>>> >
>>> > Kathy
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Aug 19, 2014 at 7:27 PM, Achim Gottinger <achim at ag-web.biz>
>>> wrote:
>>> >
>>> >> Am 20.08.2014 04:09, schrieb Kathy:
>>> >>
>>> >>  Thanks for the reply, John.  I already do have follow symlinks = yes
>>> set
>>> >>> in
>>> >>> my smb.conf file but it doesn't appear to be honoring it outside the
>>> >>> /datavol/asic filesystem.
>>> >>>
>>> >>> Kathy
>>> >>>
>>> >>>
>>> >>> On Tue, Aug 19, 2014 at 5:50 PM, Taylor, Jonn <
>>> jonnt at taylortelephone.com>
>>> >>> wrote:
>>> >>>
>>> >>>          follow symlinks (S)
>>> >>>>             This parameter allows the Samba administrator to stop
>>> smbd(8)
>>> >>>> from following symbolic links in a particular share. Setting this
>>> >>>> parameter to no
>>> >>>>             prevents any file or directory that is a symbolic link
>>> from
>>> >>>> being followed (the user will get an error). This option is very
>>> useful
>>> >>>> to stop users
>>> >>>>             from adding a symbolic link to /etc/passwd in their home
>>> >>>> directory for instance. However it will slow filename lookups down
>>> >>>> slightly.
>>> >>>>
>>> >>>>             This option is enabled (i.e.  smbd will follow symbolic
>>> >>>> links) by default.
>>> >>>>
>>> >>>>             Default: follow symlinks = yes
>>> >>>>
>>> >>>> On 08/19/2014 07:18 PM, Kathy wrote:
>>> >>>>
>>> >>>>> Hello everyone --
>>> >>>>>
>>> >>>>> I am stumped on this issue, mostly because I'm not quite sure if
>>> it's
>>> >>>>> behaving correctly or not.  I believe this used to work and right
>>> now
>>> >>>>> I'm
>>> >>>>> not quite sure why it's no longer doing so and how to fix it (if
>>> >>>>>
>>> >>>> possible).
>>> >>>>
>>> >>>>>   I suspect it is because of my recent update of the OS and Samba
>>> >>>>> version.
>>> >>>>>
>>> >>>>> When users are trying to follow a symlink that goes to a different
>>> >>>>>
>>> >>>> mounted
>>> >>>>
>>> >>>>> filesystem on the same Samba server, they are getting:
>>> >>>>> *  reduce_name: Bad access attempt: <path> is a symlink outside the
>>> >>>>> share
>>> >>>>> path*
>>> >>>>>
>>> >>>>>
>>> >>>>> I have a server that is both an NFS and a Samba server.  It is
>>> running
>>> >>>>>
>>> >>>> RHEL
>>> >>>>
>>> >>>>> 5.10 and Samba 3.0.33 (native RHEL packages). I recently patched
>>> from
>>> >>>>> 5.2
>>> >>>>> to 5.10 and this also updated Samba to the current release.
>>> >>>>>
>>> >>>>> My smb.conf file has me exporting /datavol/asic.as
>>> \\myserver\asic.
>>> >>>>> This works just fine for all users on Windows for files/subdirs in
>>> that
>>> >>>>> /datavol/asic path.
>>> >>>>>
>>> >>>>> The problem comes when they try to get to files that are
>>> softlinked to
>>> >>>>> /globalscratch2 from /datavol/asic directories.
>>> >>>>>
>>> >>>>> I have tried this both with and without exporting /globalscratch2
>>> via
>>> >>>>> Samba.  Same results.
>>> >>>>>
>>> >>>>> Previously, I had not exported /globalscratch2.
>>> >>>>>
>>> >>>>> If someone had a simlink that was like this:
>>> >>>>>
>>> >>>>> /datavol/asic/banshee/sim --> /globalscratch2/banshee/sim
>>> >>>>>
>>> >>>>> They would be able to get to it with this path no problem:
>>> >>>>> \\myserver\banshee\sim
>>> >>>>>
>>> >>>>> Any non-symbolic link subdirs are accessible just fine like this
>>> >>>>> \\myserver\banshee\localsubdir
>>> >>>>>
>>> >>>>> I have another scratch dir NFS mounted on myserver as
>>> /globalscratch.  I
>>> >>>>>
>>> >>>> am
>>> >>>>
>>> >>>>> not exporting this via Samba from myserver because it doesn't own
>>> the
>>> >>>>> filesystem.  I would understand the "symlink outside the share
>>> path"
>>> >>>>> with
>>> >>>>> an NFS mount on myserver, although from myserver's perspective it
>>> is a
>>> >>>>> local file system.
>>> >>>>>
>>> >>>>> I have always had the following in my smb.conf file:
>>> >>>>>
>>> >>>>> follow symlinks = yes
>>> >>>>>
>>> >>>>> I have tried adding:
>>> >>>>>
>>> >>>>> wide links = yes
>>> >>>>> AND
>>> >>>>> unix extensions = no
>>> >>>>>
>>> >>>>> to both the [global] section and to my share definition and nothing
>>> >>>>>
>>> >>>> works.
>>> >>>>
>>> >>>>> Is there a way to get this to work?  IS it something that can work
>>> in
>>> >>>>>
>>> >>>> later
>>> >>>>
>>> >>>>> versions of Samba.  I know it used to.  Both my users and I
>>> remember it
>>> >>>>> working so I know I'm not completely crazy.
>>> >>>>>
>>> >>>>> Thanks!
>>> >>>>>
>>> >>>>> Kathy
>>> >>>>>
>>> >>>> --
>>> >>>> To unsubscribe from this list go to the following URL and read the
>>> >>>> instructions:  https://lists.samba.org/mailman/options/samba
>>> >>>>
>>> >>>>  Hello Kathy,
>>> >> You can try this parameter
>>> >>
>>> >>  allow insecure wide links (G)
>>> >>
>>> >>            In normal operation the option wide links which allows the
>>> >> server to follow symlinks outside of a share path is automatically
>>> disabled
>>> >> when unix
>>> >>            extensions are enabled on a Samba server. This is done for
>>> >> security purposes to prevent UNIX clients creating symlinks to areas
>>> of the
>>> >> server file
>>> >>            system that the administrator does not wish to export.
>>> >>
>>> >>            Setting allow insecure wide links to true disables the link
>>> >> between these two parameters, removing this protection and allowing a
>>> site
>>> >> to configure the
>>> >>            server to follow symlinks (by setting wide links to "true")
>>> >> even when unix extensions is turned on.
>>> >>
>>> >>            If is not recommended to enable this option unless you
>>> fully
>>> >> understand the implications of allowing the server to follow symbolic
>>> links
>>> >> created by UNIX
>>> >>            clients. For most normal Samba configurations this would be
>>> >> considered a security hole and setting this parameter is not
>>> recommended.
>>> >>
>>> >>            This option was added at the request of sites who had
>>> >> deliberately set Samba up in this way and needed to continue
>>> supporting
>>> >> this functionality without
>>> >>            having to patch the Samba code.
>>> >>
>>> >>            Default: allow insecure wide links = no
>>> >>
>>> >>
>>> >> --
>>> >> To unsubscribe from this list go to the following URL and read the
>>> >> instructions:  https://lists.samba.org/mailman/options/samba
>>> >>
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>
>>
>>
>


More information about the samba mailing list