git patch 'client managed wide links (w documentation updated)'....

[Linda Walsh]

Andrew Bartlett wrote:
> Firstly, thankyou for the patch, and the included documentation. Due to
> timing, this can't be landed for 3.6.0, and will need careful review,
> particularly by the members of the Samba Team who designed the
> restriction.
---- 

Well, it's back-portable to the 3.5 series, so we could start there!  :-)


> 
>> So far the comments have been overwhelming....
> 
> I think my fellow team members who would normally comment are currently
> a little overwhelmed trying to get 3.6.0 out the door.  
---- 

Didn't understand what logistics were going on, (and someone else told me
Jeremy was out of town for a week.   It was he who indicated I sould submit
a patch that he would have to approve when this was discussed back in 
April 2010).

I understand the idea of 'feature freeze'...but what's the policy on
backporting features?

> Getting this into bugzilla will help ensure it's not lost. 
---

Sure....though give it's a fix for a 'regression' introduced by a security
fix, I would think it of high importance & priority, no?


> I would however start by noting that we understand the difficulties
> here, and have discussed this at length with other users who found our
> security stance difficult.  Adding another parameter would gain some of
> the 'informed consent' required to obtain the previous behaviour, but it
> still has drawbacks - our broader user base is notorious for setting
> dozens of unnecessary parameters based on old or specific examples found
> on the web.  I fear that users adding this may not have actually read
> the smb.conf manpage, and so become exposed to the issue again
> unwittingly. 
----- 

That's why it was named what it was.  It makes it clear that the wide
links can be managed by clients -- the same as allowing server-users to
create 'symlinks'.     I thought making it clear that such links would be
'manageable' on client machines by users, would clarify it effect.

More importantly -- WHERE would the general user base learn of this
parameter if they don't read about it in in the smb.conf manpage?

If they use testparm -v and print out all params and start setting
them at random, then, are you claiming that setting parameters at random
without reading the manpage as to their effect is something the samba team
supports or feels responsible for?   There's due diligence and common
sense which we are assuming wouldn't apply, but randomly turning params on
and off without reading the documentation would seem to be extremely
foolhardy -- and NOT something that should be *prevented* -- as the cost
to anyone showing common sense is very high.   It's not like they 'die' if
this happens, so the Darwinian effect won't be able to come into play, but
playing nanny-state for people is bad for them and society in general.   

The samba team did the right thing in putting warnings around the old
behavior and disabling it -- it's a nasty security risk if your security
relies on users not having access to the server, but for those users who
don't have such a security setup, not having this feature kills
functionality -- especially, given the more truthful nature of the 'wide
links' restriction as spelled out in the new docs.

If it allowed 'wide-links' to OTHER shares that were exported to the same
user, then I wouldn't have noticed the problem (at least not immediately).
I have used a symlink in my home-dir to '/dev/null', as a convenient way
to test I/O without involving the file system, but that was a test
situation and I don't know if my 'dev' directory is normally exported....   

But it was links to things that were 'shared'  but under different names
-- like reusing my 'doc' dir for my linux userid, and my 2-4 windows id's
(mostly mapped to 2 id's) -- namely my non-domain logins for XP and Win7
and my domain-logins for XP and Win7 (setup for historical reasons, but
still useful when domain isn't functioning).  My local userid's came first
with user-level share, then came roaming profiles (with local id's on win,
settable with group policy), and finally came domain roaming profiles).

So the roaming profiles -- especially those of the local and domain users
can show up as different to Windows and need separate dirs to function
reliably, but they can share dirs with common groups that are located in
the original profile.

I have multiple dirs setup this way -- and I notice the problem immediate
when I start firefox -- which has a background image on about:blank.  It's
located in my serverhome dir under 'Pictures', which is a link to 'the
pictures dir in my 'non-domain' login dir, even though I'm signed in with
my Domain login -- it uses the same dir (which itself is a symlink into
the docs dir (which is another symlink!)....

I use links all over the place, so this feature would make my system
unmanageable -- and I doubt I'm the only one who's used some of these
features.

Even on a temp basis, on the server, I've moved doc dirs from their normal
/usr/ under share, to point to /home/share -- another "samba share", which
meant my doc pointers on my system started failing on my clients even
though it worked on linux.  It was a temp situation until I resized the
partition, but such simple workarounds are precluded (though an rbind
would have worked in that situation, but not so easily in other
situations.

Sorry for the long response, I'm sure you've heard it all before, but at
the time, this feature first bit me (and others), Jeremy made the
suggestion that I submit a patch and write the accompanying documentation
that he would have to approve, so I'm only now getting to that, since
at the time, I took the easy way and just patched
my local copy.   

It was a system upgrade that put official binaries on my system again,
and it took a bit before I realized what the problem was.   Thus I thought
it time to get the patch in ASAP and possibly backported to the 3.5 series
as well as that's what my system keep wanting to auto-update with at this
point...

Will be happy to also submit an issue in bugtraq....I /tend/ to be good
about those things...
;-)