Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] widelinks_warning - but unix extensions *are* off

762 views
Skip to first unread message

Thomas Werschlein

unread,
Oct 29, 2015, 12:50:04 PM10/29/15
to
Hi all

Since we changed our installation from Samba 3.x to 4.x (currently 4.2.5 on Solaris 11.1), we repeatedly encounter the following 'widelinks_warning', originating from Windows Server 2012 R2 RDS clients:

[2015/10/29 15:50:38.837702, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'data' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
[2015/10/29 15:50:38.838518, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'group' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
[2015/10/29 15:50:38.839070, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'web' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.

The strange thing is: "unix extensions" *are* actually off. "wide links" are on, since we use them for vfs_shadow_copy2 (but not on the affected shares):

# testparm -sv 2>/dev/null |egrep 'wide links|unix extensions'
unix extensions = No
allow insecure wide links = No
wide links = Yes

The affected shares (data, group, web) are distinct from "working" ones, by the fact that "hide unreadable" is set to "Yes" on the affected shares only. This is how the affected shares are configured:

[data]
path = /pool1/data
read only = No
acl map full control = No
ea support = Yes
nt acl support = No
hide unreadable = Yes
map archive = No
map readonly = no
store dos attributes = Yes
vfs objects = zfsacl full_audit

Unfortunately, we can't trigger the behaviour. It's all pretty fuzzy, but maybe someone out there has an idea what's going on?

Best, Thomas







--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Jeremy Allison

unread,
Oct 29, 2015, 6:30:06 PM10/29/15
to
That message is coming from here:

void widelinks_warning(int snum)
{
if (lp_allow_insecure_wide_links()) {
return;
}

if (lp_unix_extensions() && lp_wide_links(snum)) {
DEBUG(0,("Share '%s' has wide links and unix extensions enabled. "
"These parameters are incompatible. "
"Wide links will be disabled for this share.\n",
lp_servicename(talloc_tos(), snum) ));
}
}

so it's pretty simple. Both must be being seen to emit the message.
Can you get this reproducible ?

Thomas Werschlein

unread,
Oct 30, 2015, 6:30:03 AM10/30/15
to
I am aware of the code above. What I don't grasp is: what is turning on "unix extensions", under what circumstances? I can access all the affected shares from the same clients without triggering the warning (no surprise, since "unix extensions" is globally turned off). So no, I am not able to reproduce it.

I increased the log level, but since this is a pretty busy production system and the warning appears every second day only, it was not feasible (at least I did not find a way yet). But thanks for your pointer!

Rowland Penny

unread,
Oct 30, 2015, 6:50:03 AM10/30/15
to
Hi , it might help if you posted your entire smb.conf rather than a
fragment. If you read the smb.conf manpage, under 'wide links' there is
this:

Due to this problem, this parameter will be automatically disabled (with
a message in the log file) if the unix
extensions option is on.

So, for whatever reason, samba seems to think that the unix extensions
are on.

Rowland

L.P.H. van Belle

unread,
Oct 30, 2015, 7:50:04 AM10/30/15
to
I suggest you try something like.


Global smb.conf options:
unix extensions = No
allow insecure wide links = Yes

Per share smb.conf options:
## and share options niet global used.
wide links = yes
follow symlinks = yes



> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland Penny
> Verzonden: vrijdag 30 oktober 2015 11:46
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] widelinks_warning - but unix extensions *are* off

Thomas Werschlein

unread,
Nov 2, 2015, 10:20:03 AM11/2/15
to
Sorry for the delay and thanks for your pointers.

"allow insecure wide links" does not change the behaviour, tried that before. Which is strange, if you look at the code.

On the other hand it is clearly not a static misconfiguration, otherwise I would be able to reproduce it.

About half of the time, we get a PANIC about 5 to 10 minutes after these strange widelinks_warnings appear in the logfile. It just happened again:

[2015/11/02 15:26:02.611300, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'data' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
[2015/11/02 15:26:02.706290, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'group' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
[2015/11/02 15:26:03.010964, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'web' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
[2015/11/02 15:33:27.613228, 0] ../source3/lib/popt_common.c:68(popt_s3_talloc_log_fn)
talloc: access after free error - first free may be at <E0>^A
[2015/11/02 15:33:27.616936, 0] ../source3/lib/popt_common.c:68(popt_s3_talloc_log_fn)
Bad talloc magic value - access after free
[2015/11/02 15:33:27.618304, 0] ../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 12270): Bad talloc magic value - access after free
[2015/11/02 15:33:27.636001, 0] ../source3/lib/util.c:899(log_stack_trace)
BACKTRACE: 43 stack frames:
#0 /usr/local/samba-4.2.5/lib/libsmbconf.so.0'log_stack_trace+0x2b [0xfd9e18d8]
#1 /usr/local/samba-4.2.5/lib/libsmbconf.so.0'smb_panic_s3+0x80 [0xfd9e173f]
#2 /usr/local/samba-4.2.5/lib/libsamba-util.so.0.0.1'smb_panic+0x2a [0xfe758fc6]
#3 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'talloc_abort+0x44 [0xfe6a2647]
#4 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'talloc_abort_access_after_free+0x20 [0xfe6a26f0]
#5 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'talloc_chunk_from_ptr+0x63 [0xfe6a277f]
#6 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free+0x35 [0xfe6a43d1]
#7 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'fsp_free+0x218 [0xfe2c1460]
#8 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'file_free+0x17e [0xfe2c164f]
#9 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbXsrv_open_close+0x668 [0xfe3a93a3]
#10 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbXsrv_open_destructor+0x34 [0xfe3a8142]
#11 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free_internal+0x154 [0xfe6a3352]
#12 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free_children_internal+0x76 [0xfe6a411c]
#13 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free_internal+0x2ae [0xfe6a34ac]
#14 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free_children_internal+0x76 [0xfe6a411c]
#15 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free_internal+0x2ae [0xfe6a34ac]
#16 /usr/local/samba-4.2.5/lib/private/libtalloc.so.2.1.2'_talloc_free+0xe5 [0xfe6a4481]
#17 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'exit_server_common+0x59d [0xfe3aae00]
#18 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'0x1aaf32 [0xfe3aaf32]
#19 /usr/local/samba-4.2.5/lib/private/libsmbd-shim-samba4.so'exit_server_cleanly+0x2a [0xfd6c0f51]
#20 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'dup_smb2_vec4+0x0 [0xfe37860d]
#21 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_request_create_done+0x81c [0xfe386826]
#22 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'_tevent_req_notify_callback+0x5c [0xfe62606c]
#23 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_request_pending_queue+0x44 [0xfe378ea2]
#24 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_request_process_create+0x7e9 [0xfe385f23]
#25 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_request_dispatch+0xfc1 [0xfe37c55b]
#26 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_io_handler+0x72f [0xfe37fe95]
#27 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_smb2_connection_handler+0x55 [0xfe37ffa8]
#28 /usr/local/samba-4.2.5/lib/libsmbconf.so.0'run_events_poll+0x483 [0xfd9fdd19]
#29 /usr/local/samba-4.2.5/lib/libsmbconf.so.0's3_event_loop_once+0x18a [0xfd9fdfe5]
#30 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'_tevent_loop_once+0xf3 [0xfe62489f]
#31 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'tevent_common_loop_wait+0x26 [0xfe624b01]
#32 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'_tevent_loop_wait+0x1d [0xfe624bb3]
#33 /usr/local/samba-4.2.5/lib/private/libsmbd-base-samba4.so'smbd_process+0xc07 [0xfe36375c]
#34 /usr/local/samba-4.2.5/sbin/smbd'smbd_accept_connection+0x435 [0x805b021]
#35 /usr/local/samba-4.2.5/lib/libsmbconf.so.0'run_events_poll+0x483 [0xfd9fdd19]
#36 /usr/local/samba-4.2.5/lib/libsmbconf.so.0's3_event_loop_once+0x18a [0xfd9fdfe5]
#37 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'_tevent_loop_once+0xf3 [0xfe62489f]
#38 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'tevent_common_loop_wait+0x26 [0xfe624b01]
#39 /usr/local/samba-4.2.5/lib/private/libtevent.so.0.9.25'_tevent_loop_wait+0x1d [0xfe624bb3]
#40 /usr/local/samba-4.2.5/sbin/smbd'smbd_parent_loop+0xa5 [0x805be67]
#41 /usr/local/samba-4.2.5/sbin/smbd'main+0x19e3 [0x805da17]
#42 /usr/local/samba-4.2.5/sbin/smbd'_start+0x83 [0x8055ec3]
[2015/11/02 15:33:27.662048, 0] ../source3/lib/dumpcore.c:318(dump_core)
dumping core in /usr/local/samba-4.2.5/var/cores/smbd

Regards, Thomas

Rowland Penny

unread,
Nov 2, 2015, 10:30:03 AM11/2/15
to
On 02/11/15 15:09, Thomas Werschlein wrote:

Well he didn't write what I asked for, can you please post your entire
smb.conf, please do not use testparm, please post as is (although you
can sanitise any sensitive info)

Thomas Werschlein

unread,
Nov 2, 2015, 12:20:04 PM11/2/15
to
> On 02.11.2015, at 16:25, Rowland Penny <rowlandpe...@gmail.com> wrote:
>
> Well he didn't write what I asked for, can you please post your entire smb.conf, please do not use testparm, please post as is (although you can sanitise any sensitive info)

Sorry, missed that part. Here we go.
Regards, Thomas

[global]
available = yes
smb2 leases = yes
dbwrap_tdb_mutexes:* = yes

fruit:resource = xattr
kerberos method = system keytab

smb ports = 445

log level = 0
log file =/usr/local/samba-4.2.5/var/logs_per_client/log.%m

max open files = 262144

realm = D.SOME.ORG.TLD
workgroup = D
security = ADS
disable netbios = yes
local master = no
domain master = no

host msdfs = no

idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
idmap config D : backend = nss
idmap config D : range = 1000-999999
idmap negative cache time = 0

netbios name = FSRV
server signing = auto
create mask = 0644
server string =
hide dot files = yes
hide files = /Maildir/$RECYCLE.BIN/desktop.ini
load printers = no
printing = bsd
printcap name = /dev/null
deadtime = 15

interfaces = 192.168.222.77/32
bind interfaces only = yes

unix extensions = no

map untrusted to domain = yes

username map script = /usr/local/samba-4.2.5/etc/samba/mapcomputers.sh

shadow:snapdir = .zfs/snapshot
shadow:sort = desc
shadow:localtime = yes
shadow:format = %Y%m%d%H%M
wide links = yes

vfs objects = full_audit
full_audit:prefix = %u|%I|%m|%S
full_audit:success = mkdir rename rmdir pwrite
full_audit:failure = none
full_audit:facility = LOCAL7
full_audit:priority = NOTICE

aio read size = 1
aio write size =1

[homes]
path = /pool1/home/%S
read only = no
browseable = no
create mask = 0640
directory mask = 0750
ea support = yes
store dos attributes = yes

vfs objects = shadow_copy2 fruit streams_xattr zfsacl full_audit
nt acl support = yes
inherit acls = no

[group]
read only = no
path = /pool1/group
hide unreadable = yes
comment = Group spaces of %U
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
ea support = yes
store dos attributes = yes
map archive = No
map hidden = No
map system = No
map readonly = No
vfs objects = fruit streams_xattr zfsacl
acl map full control = False
nt acl support = no
inherit acls = no

[web]
read only = no
path = /pool1/web
hide unreadable = yes
comment = Web spaces
create mask = 0664
directory mask = 0775
force create mode = 0664
force directory mode = 0775
ea support = yes
store dos attributes = yes
map archive = No
map hidden = No
map system = No
map readonly = No
vfs objects = zfsacl full_audit
acl map full control = False
nt acl support = no
inherit acls = no

[data]
path = /pool1/data
hide unreadable = yes
read only = no
ea support = yes
store dos attributes = yes
map archive = No
map hidden = No
map system = No
map readonly = No
vfs objects = zfsacl full_audit
acl map full control = False
nt acl support = no
inherit acls = no

Rowland Penny

unread,
Nov 2, 2015, 2:30:04 PM11/2/15
to
'unix extensions' is supposed to be set as a global option and if turned
on, is supposed to automatically turn off 'wide links'. However 'wide
links' has been set to on, but globally rather than on a share by share
basis, this should turn off the warning message you are getting, but
isn't. Perhaps the reason is the way you have set 'wide links', try
using it on a share by share basis and see if it stops the messages. If
that doesn't work, you could try adding 'allow insecure wide links' to
the global section of your smb.conf

Rowland

Thomas Werschlein

unread,
Nov 3, 2015, 6:00:03 AM11/3/15
to
Thanks for pointing out that 'wide links' is a per share option. We (mis-)used it as global option ever since samba 3.5.x, when the default for 'wide links' changed. Made it a share option now. I'll report back if it stopped the messages.

Best, Thomas

Thomas Werschlein

unread,
Nov 4, 2015, 10:00:04 AM11/4/15
to
Still throwing the warning message. Now that 'wide link=yes' is not defined as default for every share, it's clear that samba gets it's config messed up somehow:

[2015/11/04 13:51:51.777783, 0] ../source3/param/loadparm.c:4306(widelinks_warning)
Share 'web' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.

The share 'web' does not have vfs_shadow_copy2 enabled, therefore no need for 'wide links'. Still, the warning message pops up (and no, 'allow insecure wide links' does not prevent it neither). BTW: I just double checked, defining 'wide link' in the global section is fine according to the man page. No misuse there.

To me, it still looks like a nasty runtime problem, not a configuration issue.

Regards, Thomas

L.P.H. van Belle

unread,
Nov 4, 2015, 11:10:03 AM11/4/15
to
Again...

Global ONLY smb.conf options:
unix extensions = No
allow insecure wide links = Yes

Per share ONLY smb.conf options:
## and share options niet global used.
wide links = yes
follow symlinks = yes

unix extensions are enabled =>> wide links are disabled automaticly.
Set : allow insecure wide links = Yes
I dont see it in you smb.conf..

wide links = yes is in you GLOBAL smb.conf and not in the share..

Review your setup again, you have configuation errors!
man smb.conf
Its all there..


Greetz,

Louis





> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Thomas Werschlein
> Verzonden: woensdag 4 november 2015 15:58
> Aan: Rowland Penny
> CC: sa...@lists.samba.org
> Onderwerp: Re: [Samba] widelinks_warning - but unix extensions *are* off
>
>

Thomas Werschlein

unread,
Nov 4, 2015, 11:40:04 AM11/4/15
to
This is getting nowhere ...

man smb.conf yourself: "All S parameters can also be specified in the [global] section - in which case they will define the default behavior for all services." If you have any special knowledge about why this should not be applicable for "wide links", please elaborate.

Thomas

L.P.H. van Belle

unread,
Nov 4, 2015, 12:00:03 PM11/4/15
to

Sure, but did you even try my advice.. ??

So again.. from smb.conf

unix extensions (G)
allow insecure wide links (G)
wide links (S)
follow symlinks (S)
G = Global
S = Share


So here you are lazy ... ( fill the dots..) ;-)
Read below .... from : man smb.conf

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

unix extensions (G)
This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features
such as symbolic links, hard links, etc... These extensions require a similarly enabled client, and are of no current use to Windows clients.

Note if this parameter is turned on, the wide links parameter will automatically be disabled.
See the parameter allow insecure wide links if you wish to change this coupling between the two parameters.
Default: unix extensions = yes

wide links (S)
This parameter controls whether or not links in the UNIX file system may be followed by the server. Links that point to areas within the directory tree exported by the server are always allowed; this parameter controls access only to areas that are outside the directory tree being exported.

Note: Turning this parameter on when UNIX extensions are enabled will allow UNIX clients to create symbolic links on the share that can point to files or directories outside restricted path exported by the share definition. This can cause access to areas outside of the share. Due to this problem, this parameter will be automatically disabled (with a message in the log file) if the unix extensions option is on.

See the parameter allow insecure wide links if you wish to change this coupling between the two parameters.
Default: wide links = no


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

So again..
Your setup is incorrect, if you wont look/read..
well, you on your own then.


Greetz,

Louis

> -----Oorspronkelijk bericht-----
> Van: Thomas Werschlein [mailto:thomas.w...@geo.uzh.ch]
> Verzonden: woensdag 4 november 2015 17:31
> Aan: L.P.H. van Belle

Thomas Werschlein

unread,
Nov 5, 2015, 9:00:05 AM11/5/15
to
You tried to be helpful. I appreciate that, thank you.

Best, Thomas

Linda W

unread,
Nov 7, 2015, 6:30:03 PM11/7/15
to
L.P.H. van Belle wrote:
> # G = Global, S = Share
> unix extensions (G)
> allow insecure wide links (G)
> wide links (S)
> follow symlinks (S)
>
> 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[sic] 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.
---

Depends on whether you come from a linux/unix background vs.
a windows background. Windows setups tend not to allow users to login
to the server because windows has been too vulnerable to privilege
escalation in the past.

The same _may_ be true on unix systems, but in the unix
environments I've worked in, the unix users in a given "domain" (like
"Eng[ineering]"), were considered to be trusted and responsible users
that did have and were given access to Servers in the "Eng" domain.
"If they were not trusted and responsible, then why would the company
hire them?", i.e. why would the company have then as employees?

Given the defaults, above, there is no such thing as an "insecure
wide link". Since All the users in a domain could already login to
the server and create links wherever the unix-permissions (UID/GID)
allowed -- and, as symlinks -- they could point anywhere -- including
/dev/null or /../nowhere. I.e. symlinks were never trusted the way
"hard links" were trusted.

Similarly, hardlinks to protected files were not a problem, since
you can't create hardlinks in any directory you didn't have write and
execute access to (and read in some cases). At the same time, you
can't change access bits on a hard-linked file unless you were already
the owner. So creating a hardlink to /etc/passwd didn't give you any
rights you didn't already have with /etc/passwd.

Making the above secure also involved other good practices like
keeping user-writable partitions separate from OS partitions (and
maybe separate from daemon-writable partitions). As well assigning
a separate GID to each UID, and having a security system that allows
GID-nesting just as one can add multiple UID's to a group. Systems
like Win-domains+AD's, and NIS/YP both allow such nesting.

So people coming from a trusted-employee background that had these
features saw no problem with "unix-extensions" co-existing with
"widelinks" as the security models in which they existed made
things *more* secure than many of the workarounds and, especially, the
associated *mindsets* (i.e. defaulting to hiring non-trust-worthy
employees; note: "eng" domain users still were walled off from "legal"
or "corporate" domains as the *types* of information each domain dealt
with were of different sensitivity levels (cf. Chinese-Wall security
setups).

Samba became a mixing round of employees coming from both types of
backgrounds -- the trusting type, and the Win-type where every
privilege or restriction usage/violation was an auditable event and
privileges to even edit your own desktop are finely grained and
controlled.

That was very different from the default "trusted eng-devel
background", make this issue a hot spot where the
trusted-background/chinese-wall type security setups were mostly
forgotten about and categorically labeled "insecure" ("allow insecure
wide links" used to be called "allow client managed wide links" --
saying exactly what they did rather than some blind "insecure" label).

Anyway, to address the problem you run into, have your share's use
"includes". At the global level have the global option needed:

allow insecure wide links = yes (G)
# unix extentions = yes (default)

---
Then have multiple "share-include files":

> ls *share*.inc
ro_share.inc shares+recyl+shadcop.inc
shares+recycle.inc shares_basic.inc

> egrep 'include|share|wide' *.inc

ro_share.inc: wide links = yes

shares_basic.inc: wide links = yes
shares_basic.inc:# follow symlinks = yes (default)

shares+recycle.inc: include = /etc/samba/inc/shares_basic.inc
shares+recyl+shadcop.inc: include = /etc/samba/inc/shares_basic.inc


Note, wide-links are enabled in the basic and read-only
shares and other share-types include one of those.
Also in the ".inc" files are options I wanted to be
common to those shares like block-size, acl-inherit,
vfs objects...etc.

Note, that the normal practices that supported the above
security, like separating partitions -- is going in the
opposite extreme where people are converting distro's to
support "appliance" or "console" type applications where
everything is on 1 partition.

To support the lack of secure defaults that supported
schemes like the above, linux has added 2 new options
that are relevant to these setups:

> ls /proc/sys/fs/*link*
/proc/sys/fs/protected_hardlinks /proc/sys/fs/protected_symlinks
---

In distro's aiming to support appliances intended for untrusted
users (game-console manufaturers, mobile-phone creators,
"walled garden" platforms), you'll likely find
those options being set to "1", by default, during the
bootup process.

Being about links of both varieties they are likely to have
interactions with samba's processing - so you might want to
ensure those options are set to values that work in your
setup.

Hopefully this will help lessen the work you need to do
to get around those imposing different (and functionality
breaking) security models -- at least for now...


Linda Walsh

L.P.H. van Belle

unread,
Nov 9, 2015, 2:30:04 AM11/9/15
to
Thanks you, an email to save, good info.
I didnt know about the : proc/sys/fs/protected_hardlinks

Thanks !

Louis
> -----Oorspronkelijk bericht-----
> Van: Linda W [mailto:sa...@tlinx.org]
> Verzonden: zondag 8 november 2015 0:18
> Aan: thomas.w...@geo.uzh.ch
> CC: L.P.H. van Belle; sa...@lists.samba.org
> Onderwerp: Re: widelinks_warning - but unix extensions *are* off
0 new messages