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
>>>
>>
>>
>>
>
