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)
comment:3 follow-up: 4 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 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 follow-up: 7 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 Changed 13 years ago by danielluke (Daniel J. Luke)
Resolution: | → invalid |
---|---|
Status: | new → closed |
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).
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?