clamav 0.97.3 not building on OS/X Lion 10.7.2 b/c of "missing" clamav user

[captainproton1971@…]

(I think this might be related to ticket #31154)

Looking at the output of port -v install clamav, it seems that the configure script is looking for a file /usr/bin/nidump which hasn't been part of OS/X since 10.5. For some reason, the configure script run by MacPorts seems to trying nidump rather than dscl.

The relevant output is

bash-3.2# port install clamav

--->  Computing dependencies for clamav
--->  Configuring clamav

(blah blah blah)...

checking for sched_yield... yes
checking for pthread_yield... no
checking for enable_extended_FILE_stdio... no
checking for readdir_r... support disabled
checking for ctime_r... yes, and it takes 2 arguments
checking for socklen_t... yes
checking for clamav in /etc/passwd... checking for clamav using netinfo... ./configure: line 17550: /usr/bin/nidump: No such file or directory
./configure: line 17551: /usr/bin/nidump: No such file or directory
no
configure: error: User clamav (and/or group clamav) doesn't exist. Please read the documentation !

Interestingly enough, I can successfully configure (./configure) and compile (make) from the /opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/clamav directory. In doing this, it seems that the configure script uses dscl rather than nidump.

bash-3.2# ./configure  | grep passwd
rm: conftest.so.dSYM: is a directory
checking for clamav in /etc/passwd... checking for clamav using dscl... yes, user clamav and group clamav

I'm guessing that there are some configure options being passed by the Portfile that are interfering, but I'm not clever enough to locate the problem.

[dluke@…]

What does your /usr/bin/dscl look like on the machine where this is failing?

The configure script should only fall back to nidump if /usr/bin/dscl is not executable.

Maybe you changed the permissions on /usr/bin/dscl at some point in time in the past?

[dluke@…]

For reference, on my 10.7.2 system:

% ls -l /usr/bin/dscl
-rwxr-xr-x  1 root  wheel   267K Sep 18 20:22 /usr/bin/dscl*% file /usr/bin/dscl
/usr/bin/dscl: Mach-O universal binary with 2 architectures
/usr/bin/dscl (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/dscl (for architecture i386):	Mach-O executable i386
%% openssl sha256 /usr/bin/dscl
SHA256(/usr/bin/dscl)= 6cdb16590594e8ea8ae77c26ef8bd4e780028a9e08d6a56e6437b21e406f001b

[dluke@…]

(fix formatting)

For reference, on my 10.7.2 system:

% ls -l /usr/bin/dscl
-rwxr-xr-x  1 root  wheel   267K Sep 18 20:22 /usr/bin/dscl*

% file /usr/bin/dscl
/usr/bin/dscl: Mach-O universal binary with 2 architectures
/usr/bin/dscl (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/dscl (for architecture i386):	Mach-O executable i386

% openssl sha256 /usr/bin/dscl
SHA256(/usr/bin/dscl)= 6cdb16590594e8ea8ae77c26ef8bd4e780028a9e08d6a56e6437b21e406f001b

[dluke@…]

also, this isn't related to #31154 (in that case, the configure script was using dscl, but on that person's machine the clamav user did not exist)

[captainproton1971@…]

Aha! I think you've hit on it -- permissions on dscl. I had restricted these permissions a while back to mitigate a potential password exposure vulnerability (and, of course, had forgotten that I had done it). This must have been interfering with the configuration script run by MacPorts.

I'm a little unclear as to why dscl worked when I ran the script manually while it didn't through MacPorts -- does the port system drop privileges when building?

Anyways, I've just completed the installation -- file this one as closed: submitter was an idiot

And thanks.

[dluke@…]

Replying to captainproton1971@…:

I'm a little unclear as to why dscl worked when I ran the script manually while it didn't through MacPorts -- does the port system drop privileges when building?

Yes - builds happen as the macports user/group now. (You can see this if you look at the debug or verbose output when MacPorts is building stuff).