unix exts / wide links / symlinks
in [Samba]
|
Prev: Corrent security mode settings to allow mess-windows XP behave!
Next: Kerberos method not working like use kerberos keytab?
From: Linda W on 6 Apr 2010 20:20 Jeremy Allison wrote: > On Wed, Mar 03, 2010 at 03:38:58PM +0100, Stefan Götz wrote: >> Setting the 'wide links' option to yes and/or the 'follow symlinks' to no on the >> server has no effect, neither globally nor on a per-share basis. Is there any >> other way to tell smbd to not meddle with symlinks? > > Remove the check in lp_widelinks() (param/loadparm.c) and recompile. > > We got bitten badly enough by this that I don't think > this should be a user settable parameter I'm afraid. > > Jeremy. ---- I disagree with this decision as well -- I'm bitten by this and can't mount my share and give my clients access. I use wide links and also would expect them to work on my unix-extended clients (including, I believe, cygwin on windows (?)). I don't give access to people who would abuse such privileges, so in my situation, the previous setup is far preferable. I don't want to have to recompile, from sources, EVERY future release and every future update I sometimes get *autoupdated* from my linux-vendor. As it stands -- with any autodate, or any update, I load from my vendor, I will find my whole setup failing -- as these links are key to my setup working. I'll have to recompile every update the instant it hits -- and if autoupdate is turned on -- the first I'll see is no client being able to access their personal Documents folder -- which is put in a separate location for various administrative reasons. This has really 'bit' me, by the way -- I read that I needed to explicitly turn on wide links, now, which I did -- but then still most things didn't work. Why? because wide links being turned on was ignored! Why? Because the default is unix extensions=yes, and that overrides my explicit wide links = on statement. The fix for me is not to turn off unix extensions, as I use those as well. To address your concerns and allow things to work as before, make "wide links" a tri-state: {off, on, insecure}, with insecure allowing the feature to function as before. Otherwise, there's no way I can support my current setup -- since a user's homedir doesn't physically contain their 'Documents' (this was done, by the way, because some users have have multiple profiles who want their Documents to be auto-shared across all profiles. For example, I have 2 logins: "me(a)localmachine" and "me(a)mydomain". Currently both use the same documents folder and this has been transparently handled on the server. Documents on the server is a wide-link out of the profiles to the shared Documents folder. Was working great before 3.4.5. Wouldn't the tristate allay your concerns? I can simply put 'wide links=insecure' in my global and it will enable the old behavior (regardless of the unix extensions setting). -linda meanwhile, I guess it's time to pull sources for my distro and start doing some rebuilding... what a pain. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Volker Lendecke on 7 Apr 2010 01:10 On Tue, Apr 06, 2010 at 04:44:02PM -0700, Linda W wrote: > Jeremy Allison wrote: > > On Wed, Mar 03, 2010 at 03:38:58PM +0100, Stefan Götz wrote: > >> Setting the 'wide links' option to yes and/or the 'follow symlinks' to no on the > >> server has no effect, neither globally nor on a per-share basis. Is there any > >> other way to tell smbd to not meddle with symlinks? > > > > Remove the check in lp_widelinks() (param/loadparm.c) and recompile. > > > > We got bitten badly enough by this that I don't think > > this should be a user settable parameter I'm afraid. > > > > Jeremy. > ---- > I disagree with this decision as well -- I'm bitten by this > and can't mount my share and give my clients access. I use wide links > and also would expect them to work on my unix-extended clients (including, > I believe, cygwin on windows (?)). Well, if you are slashdotted on every security mailing list on this planet, what can you do? You just close down your service. Sorry for that, but Samba just can't afford to be called insecure by default. Volker
From: Volker Lendecke on 7 Apr 2010 03:40 On Wed, Apr 07, 2010 at 08:38:50AM +0200, Stefan Götz wrote: > > Sorry for that, but Samba just can't afford to be called > > insecure by default. > > Absolutely - and I do very much respect the reasons for > that. So Linda and I are > suggesting a non-default option or option value called something like > "YesIWantToShootMyselfInTheFootAndWontComplainAboutItOnSlashdotSoTurnOnWideLinks" > instead of reverting to an insecure default. In our usage > scenarios, such a shot in the foot is something quite > desirable and useful. If you asked me, I would support that. insecure wide links and unix extensions = yes or so. Now you have to convince Jeremy to also accept it :-) Volker
From: Stan Hoeppner on 7 Apr 2010 05:40 Linda W put forth on 4/6/2010 6:44 PM: > As it stands -- with any autodate, or any update, I load from my vendor, > I will find my whole setup failing -- as these links are key to my setup working. > I'll have to recompile every update the instant it hits -- and if autoupdate is > turned on -- the first I'll see is no client being able to access their personal > Documents folder -- which is put in a separate location for various administrative > reasons. The Debian Linux package manager system allows the OP to "pin" certain packages so they are left alone during updates. IIRC, you can also configure it to notify you when a new version of a pinned package is available, so you can take any necessary action. I.e. if the package update is due to a security issue, you can go ahead manually roll a new copy with your custom patches and install it. If the update isn't a security fix, but a feature update you don't really need, you can ignore the situation until the next security update comes along, saving yourself some of the rebuild episodes. This obviously isn't an optimal solution either as it still requires some manual work. But it's a bit better than the situation you describe. Does your distro's package manager have a package pinning feature? Have you looked for a non-vendor package with the feature you need maintained by a third party? That may be an option as well. Have you checked to see if your Linux vendor maintains a version of the samba package with feature, but it's not made available via the standard channels? If more than a handful of people need a feature, in the Linux world, usually someone is maintaining a copy someone around the globe. None of these possible solutions are perfect, but one or more of them may be a little better than your current situation. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Linda W on 7 Apr 2010 06:50
Volker Lendecke wrote > > If you asked me, I would support that. > > insecure wide links and unix extensions = yes --- If I catch your drift -- we might be saying same -- if I specify 'wide links = true' or ' = insecurely_true, the former could change a '_non-specified_ default for unix extensions to "off" but generate an error if both are specified. if I use the 'insecurity_true' could again force unix extensions to off as default, but if user explicitly specifies both, then they are knowingly turning on both options and only in that case would they get the old behavior. In my setup my root dir is shared via samba, so wide links are not a security issue. I.e. In my situation, a bug was created -- no security issue was fixed. > > or so. Now you have to convince Jeremy to also accept it :-) --- Hopefully he'll convince himself -- my convincing skill are as likely as not to offput someone...;-) -l -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |