Bug 466364 – net-fs/cifs-utils-6.0: Enable cifsacl and idmap-utilities

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Torsten Kurbad 2013-04-18 12:57:58 UTC]

The current net-fs/cifs-utils isn't up to date with all possible configuration option.
E.g., for some users it might be nice to have the setcifsacl / getcifsacl binaries installed to be able to view (and possibly change) ACLs on their CIFS shares. Also, the forced use of "caps" instead of "caps-ng" seems somewhat antiquated.

Find attached a patch for the current ebuild, meant as a starting point. It proposes "caps-ng" over "caps". Also, by setting the "acl" use flag, you can choose to have the above mentioned cifsacl utilities installed.

The proper next step would be to "invent" a local use flag to activate the idmap feature on demand, which is now disabled by the '--disable-cifsidmap' configure option.

On a side note, /usr/portage/profiles/use.local.desc has to be updated. In line 3997, it says:

net-fs/cifs-utils:upcall - Create cifs.idmap binary; idmap support

Which is completely misleading. Setting USE="upcall" enables the cifs.upcall binary and enables upcall support, e.g. to be able to access DFS shares.

Best,
Torsten

Reproducible: Always

[Comment 1 Torsten Kurbad 2013-04-18 12:59:05 UTC]

Created attachment 345892 [details, diff]
cifs-utils-6.0.ebuild-enhancements.patch

[Comment 2 Lars Wendler (Polynomial-C) (RETIRED) 2013-04-18 13:44:15 UTC]

USE=caps is not forced but enabled by default.

I'd like to know why caps-ng should be preferred over caps. I'm not really deep into that matter and any insight would be nice.

The other changes look okay from my side. I'd be tempted to add all changes as asoon as I know more about the caps-ng stuff.

[Comment 3 Torsten Kurbad 2013-04-18 14:04:02 UTC]

Created attachment 345900 [details, diff]
cifs-utils-6.0.ebuild-enhancements.patch

Hi Lars,

(In reply to comment #2)
> USE=caps is not forced but enabled by default.

my bad, I chose the wrong word.

> I'd like to know why caps-ng should be preferred over caps. I'm not really
> deep into that matter and any insight would be nice.

Me neither, but if you look at cifs-utils' 'configure --help', the developers clearly prefer caps-ng:

  ...
  --with-libcap-ng=auto/yes/no  Add Libcap-ng support default=auto
  --with-libcap    Add libcap support default=yes, if libcap-ng not available
  ...

Staying with 'caps' should be fine, though.

> The other changes look okay from my side. I'd be tempted to add all changes
> as asoon as I know more about the caps-ng stuff.

Thanks for the heads up. However, I just figured, that the acl feature needs cifs.idmap, thus that had to be enabled as well. On the bright side, the need for a local 'idmap' use flag is now gone. ;-)

In this new patch, I also rewrote the ebuild to create the necessary keyutils configuration files through the new modular request-keys.d configuration directory in /etc. In my opinion, they won't do any harm to the "standard" features.

Oh, and I reverted the "accidental" default use change to '+ads'.

I hope you are still with me in this!
Torsten

[Comment 4 Lars Wendler (Polynomial-C) (RETIRED) 2013-04-22 08:04:05 UTC]

+*cifs-utils-6.0-r1 (22 Apr 2013)
+
+  22 Apr 2013; Lars Wendler <[e-mail]>
+  +cifs-utils-6.0-r1.ebuild:
+  Revbump to EAPI-5. Added a patch by Torsten Kurbad to default enable
+  libcap-ng and some additionaly tweaks in the ebuild (bug #466364). Reworked
+  USE flag logic. Now "caps" USE flag controls both caps implementations and
+  "caps-ng" is the switch between one of them.
+

[Comment 5 Torsten Kurbad 2013-04-28 19:26:29 UTC]

I'm afraid, this one needs to be re-opened.

I just tried a fresh install of net-fs/cifs-utils-6.0-r1 with "acl" use flag set, but didn't get any of the cifsacl-utilities.

Further investigation showed the reason:

During configure phase, there appears a warning I only know from my Ubuntu-machines so far

checking for WBCLIENT... no
configure: WARNING: wbclient.h not found, consider installing libwbclient-devel. Disabling cifs.idmap.
configure: WARNING: wbclient.h not found, consider installing libwbclient-devel. Disabling cifsacl.


To circumvent this, the environment variables WBCLIENT_CFLAGS and WBCLIENT_LIBS have to be set for configure like so:

WBCLIENT_CFLAGS="-I/usr/include" WBCLIENT_LIBS="-L/usr/$(get_libdir) -lwbclient"

Alternatively, wbclient's pkgconfig would have to be fixed.

I incorporated the former solution/workaround into the current ebuild. See attached patch.

Best,
Torsten

[Comment 6 Torsten Kurbad 2013-04-28 19:27:17 UTC]

Created attachment 346810 [details, diff]
cifs-utils-6.0-r1.ebuild_wbclient.patch

[Comment 7 Lars Wendler (Polynomial-C) (RETIRED) 2013-04-30 08:34:03 UTC]

wbclient.h and libwbclient.so* belong to sys-fs/samba. 
So it seems that we need to RDEPEND on samba once the acl USE flag is set...

[Comment 8 Torsten Kurbad 2013-04-30 10:18:45 UTC]

(In reply to comment #7)
> wbclient.h and libwbclient.so* belong to sys-fs/samba. 
> So it seems that we need to RDEPEND on samba once the acl USE flag is set...

Yes, obviously. I missed that one, sorry.

Anyway, I investigated a bit further:

On one of my machines, which has net-fs/samba-4.0.4 installed, installing the *etcifsacl utilities from net-fs/cifs-utils-6.0-r1 went smoothly.
That's because in case of samba4, (among others) a valid /usr/$(get_libdir)/pkgconfig/wbclient.pc got installed:

atalante ~ # equery f net-fs/samba | grep \.pc$
/usr/lib64/pkgconfig/dcerpc.pc
/usr/lib64/pkgconfig/dcerpc_atsvc.pc
/usr/lib64/pkgconfig/dcerpc_samr.pc
/usr/lib64/pkgconfig/dcerpc_server.pc
/usr/lib64/pkgconfig/gensec.pc
/usr/lib64/pkgconfig/ndr.pc
/usr/lib64/pkgconfig/ndr_krb5pac.pc
/usr/lib64/pkgconfig/ndr_nbt.pc
/usr/lib64/pkgconfig/ndr_standard.pc
/usr/lib64/pkgconfig/netapi.pc
/usr/lib64/pkgconfig/registry.pc
/usr/lib64/pkgconfig/samba-credentials.pc
/usr/lib64/pkgconfig/samba-hostconfig.pc
/usr/lib64/pkgconfig/samba-policy.pc
/usr/lib64/pkgconfig/samba-util.pc
/usr/lib64/pkgconfig/samdb.pc
/usr/lib64/pkgconfig/smbclient-raw.pc
/usr/lib64/pkgconfig/smbclient.pc
/usr/lib64/pkgconfig/smbsharemodes.pc
/usr/lib64/pkgconfig/torture.pc
/usr/lib64/pkgconfig/wbclient.pc
atalante ~ #

This one's found and accepted by cifs-utils' configure, so everything is fine without the patch I sent in Comment #6.

However, on another machine running net-fs/samba-3.6.13, no wbclient.pc exists whatsoever. In fact, not a single pkgconfig file has been installed by the samba ebuild:

kmrcserv ~ # equery f net-fs/samba | grep \.pc$
kmrcserv ~ # 

Although I think this is normal behaviour for samba 3 installations, in such cases the workaround from Comment #6 is necessary, which isn't too much of a hack, I think.

The alternative would be to "manually" create a wbclient.pc inside the net-fs/samba-3.x ebuilds, which would be more complex and thus probably more error-prone...

[Comment 9 Lars Wendler (Polynomial-C) (RETIRED) 2013-07-10 15:25:19 UTC]

+*cifs-utils-6.1 (10 Jul 2013)
+
+  10 Jul 2013; Lars Wendler <[e-mail]>
+  -cifs-utils-5.6-r1.ebuild, -cifs-utils-5.8-r1.ebuild,
+  -cifs-utils-6.0-r1.ebuild, +cifs-utils-6.1.ebuild:
+  Non-maintainer commit: Version bump. Removed old. Really fixed bug #466364
+  this time.
+
Please test cifs-utils-6.1. I've looked into the samba-3.6 ebuilds and they install all the wbclient files when the "winbind" USE flag is enabled. So cifs-utils-6.1 now depends on either =samba-3.6*[winbind] or >=samba-4 when the "acl" USE flag is enabled in cifs-utils.

Can you confirm this fixing your issue with samba-3.6?

[Comment 10 Torsten Kurbad 2013-07-12 10:44:05 UTC]

(In reply to Lars Wendler (Polynomial-C) from comment #9)
> +*cifs-utils-6.1 (10 Jul 2013)
> Can you confirm this fixing your issue with samba-3.6?

Yes, works like a charm. Thanks for the fix!

Best,
Torsten