<div dir="ltr"><div>Hi James,</div><div><br></div><div>You've hit the nail on the head re: why wide links should be left off. To explore this a bit further though, we're an abnormal use case and don't have the usual risks that article refers to.</div><div><br></div><div>In most environments, the only access users would have to the server is through Samba so anything that lives outside of a file share they can see should be invisible to them. If wide links and unix extensions are both on (which used to be possible back in the Samba 2/3 days) you could get access to things you shouldn't be able to read. The TLDR of your link (for those who haven't read it) is its as easy as mount the share with with unix extensions, make a link, then remount without them and grab the data the link points to.</div><div><br></div><div>What makes us a little different is that UCC members already have shell access to the file server and can grab any file they have read access to already. In theory wide links don't expose any files at a higher level of access than our users already have. The risk is it adds the possibility of some security flaw in Samba that allows for privilege escalation. Turning them on exposes more surface area to potentially attack but that's probably an acceptable risk in the context of UCC's /away file server - the whole point /away and /home are separate is to manage other existing risks that are present with NFS and /away.</div><div><br></div><div>That said, unix extensions are nice for everything else they bring for clients that support them. It is better to leave them on if we can come up with another solution. (In reality though I don't know how many non-windows clients are using Samba to get at /away, I'd hazard it's a rather short list). If it really comes to it, I'd offer that adding working Thunderbird/Firefox profile sharing is probably a better user experience for a greater number people so it's not something I'd strongly argue against.</div><div><br></div><div>Another options you might want to explore is adding a share for the .mozilla folder a path of %h/.mozilla on a share will give each user access to their own folder. From there you could look at a mount script or relocating the profile location in windows. It's been a long time since I poked about with Firefox/Thunderbird's profile, so apologies if that can't be done.</div><div><br></div><div>Regards,</div><div>James</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 19 Aug 2019 at 23:28, James Arcus <<a href="mailto:jimbo@ucc.asn.au">jimbo@ucc.asn.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I was just tinkering around tonight trying to allow for sharing the same <br>
Firefox & Thunderbird profile between Windows and Linux on the clubroom <br>
machines. My plan of attack was to create a symlink from the relevant <br>
locations in AppData on the Windows profiles that link back to the <br>
.mozilla/.thunderbird folders in my /away.<br>
<br>
Samba on molmol would not follow my symlinks because they lead outside <br>
the share (so-called "wide links") and wide links are disabled when <br>
Samba Unix extensions are enabled. The intention of this is to prevent a <br>
vulnerability where a Unix client creates a symlink which is then <br>
evaluated by the Samba server. See <br>
<a href="https://www.samba.org/samba/news/symlink_attack.html" rel="noreferrer" target="_blank">https://www.samba.org/samba/news/symlink_attack.html</a> for more.<br>
<br>
Disabling Unix extensions would allow my plan to work (as I verified), <br>
but does not necessarily fix the vulnerability. Given that UCC users can <br>
edit the contents of their Windows profiles freely from our user <br>
servers, I believe the same problem would exist there.<br>
<br>
For that reason, I've left wide links explicitly disabled with a <br>
comment. I'm not sure if my above assumption holds, so I'd appreciate <br>
any knowledge people have. Either that, or more investigation is needed. <br>
For example, if the "exploit" only allows reading files outside of the <br>
share that users would be able to access by logging directly in to <br>
molmol, that presents little issue. But if it allows any sort of writing <br>
or bypassing ACLs, then that's obviously more serious.<br>
<br>
Additionally, if there's another way to go about what I'm trying to <br>
achieve, then hearing that would be great too.<br>
<br>
Cheers,<br>
<br>
James [MPT]<br>
<br>
_______________________________________________<br>
List Archives: <a href="http://lists.ucc.asn.au/pipermail/tech" rel="noreferrer" target="_blank">http://lists.ucc.asn.au/pipermail/tech</a><br>
<br>
Unsubscribe here: <a href="https://lists.ucc.gu.uwa.edu.au/mailman/options/tech/frenchie%40ucc.gu.uwa.edu.au" rel="noreferrer" target="_blank">https://lists.ucc.gu.uwa.edu.au/mailman/options/tech/frenchie%40ucc.gu.uwa.edu.au</a><br>
<br>
</blockquote></div></div>