[linux-cifs-client] Re: [PATCH] Fix build error where nscd_flush_cache() is available

[Jeff Layton]

On Sun, 17 Aug 2008 00:54:00 +0400
"Q (Igor Mammedov)" <niallain at gmail.com> wrote:

> On Sun, Aug 17, 2008 at 12:00 AM, simo <idra at samba.org> wrote:
> > On Sat, 2008-08-16 at 23:40 +0400, Q (Igor Mammedov) wrote:
> >> I agree, we'd better use dynamic linking or give up on reusing samba code
> >> and revive some code from the first implementation without libsmbclient
> >> dependecy + static linking to krb5 libs. so we could end up with deps
> >> /lib located libraries only.
> >
> > Unless you plan to use cifs.upcall at boot or to mount /usr I do not see
> > why you would do that.
> >
> > Static liking is also bad for many reasons, especially for security
> > sensitive software. You do not want to get into the business of
> > releasing a new cifs.upcall binary if a security problem is found in the
> > kerberos libraries.
> >
> > Simo.
> >
> 
> Dynamic linking cons:
> Somebody here pointed out that dependency on /usr fs for this program is not
> a good thing.

I think this only matters if we're worried about trying to use
cifs+krb5 to mount / and/or /usr. While it may be possible someday,
it's not really today. This binary is already linked to a ton of shared
libs (many of which live under /usr). Adding one more seems
reasonable to me.

> Dependency on libsmbclient is not a good for embedded systems. By the way
> it's even better do not depend on libsmbclient  to reduce total size
> of OS image.
> 
> Static linking cons you already pointed out.
> 
> As for me, I'd be more comfortable with dynamic linking.
> 
> PS:
> But making cifs.spnego code independent of libsmbclient may simplify porting of
> it to small systems.
> (and less depend on bugs in libsmbclient  like this:
> https://bugzilla.samba.org/show_bug.cgi?id=5614#c28)
> It would be ideal to isolate spnego/kerberos code in quiet independent library,
> and use it in the way people would like.

I think we need to resist duplicating code here. Small systems also
benefit from shared libs when more than one binary is using the same
code. It's not hard to imagine the smbclient program installed
alongside cifs.upcall on an embedded box.

I wouldn't call this a crisis. A big binary isn't ideal but it's a
situation we can probably live with for the time being. In the long
run, it would be a nice thing if someone were to break out the code we
need for this into a new lib (maybe a libspnego.so or something).

-- 
Jeff Layton <jlayton at redhat.com>