Opened 13 years ago

Closed 13 years ago

#31672 closed defect (invalid)

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

Reported by: captainproton1971 (Captain Proton) Owned by: danielluke (Daniel J. Luke)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc:
Port: clamav

Description

(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.

Change History (7)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to dluke@…
Port: clamav added

comment:2 Changed 13 years ago by danielluke (Daniel J. Luke)

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?

comment:3 Changed 13 years ago by danielluke (Daniel J. Luke)

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

comment:4 in reply to:  3 Changed 13 years ago by danielluke (Daniel J. Luke)

(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

comment:5 Changed 13 years ago by danielluke (Daniel J. Luke)

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)

comment:6 Changed 13 years ago by captainproton1971 (Captain Proton)

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.

comment:7 in reply to:  6 Changed 13 years ago by danielluke (Daniel J. Luke)

Resolution: invalid
Status: newclosed

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).

Note: See TracTickets for help on using tickets.