exiftool / exiftool

On macOS (tested on macOS 12.2, exiftool 12.37), exiftool calls xattr to get extended attributes. The system-provided xattr lives at /usr/bin/xattr and it's called by exiftool (ref below) without the path. Because of this, if another executable called xattr is in the path, exiftool may call the wrong xattr resulting in warning "ExifTool:Warning": "Error running "xattr" to extract XAttr tags". In particular, the python xattr library installs an xattr executable (which does not use the same command line options as the system-provided xattr). If you use a python virtual environment, this will be installed in venv/bin/xattr which will likely appear in $PATH before /usr/bin meaning any use of exiftool while the python environment is activated produces the warning.

exiftool/lib/Image/ExifTool/MacOS.pm

Lines 568 to 571 in 00e4fdc

    
           my @xattr = `xattr -lx "$fn" 2> /dev/null`; # get MacOS extended attributes 
        
           if ($? or not @xattr) { 
        
               $? and $et->Warn('Error running "xattr" to extract XAttr tags'); 
        
               return;

Recommended solution: call xattr as /usr/bin/xattr on MacOS.

Edit: I've worked around this issue in my code (which calls exiftool in a subprocess) by modifying the environment passed to the subprocess so exiftool finds the correct xattr) but I think it would be better for exiftool to be explicit about which executable it wants to call.

By the way, thanks very much for all your work on exiftool -- it's a wonderful tool that I use every day! For more analysis of this particular issue, see the discussion on issue #636 over at osxphotos, a project of mine that exports photos from Apple Photos whilst preserving metadata (and optionally uses exiftool to write metadata to the photos).

Thanks for this suggestion. I suppose I should also add the path to the stat and mdls commands too (both in /usr/bin on my MacOS 10.14.6 system).

Hmmm. I'm also calling osascript (which resides in /usr/bin) and tag (from /usr/local/bin). Do you think I should force those paths for all these commands?

...and /usr/bin/setfile

Super Super Super exiftool! Thank you so much! Using it tons!!!

Warning: I'm not a Perl developer! Hope it helps!

Looking also at this topic from a security point of view I bumped into this Calling External Commands More Safely

Activating Perl's tainted mode on MacOS 12.2.1 with exiftool 12.37

As indicated by @RhetTbull my system has osxphotos and a specific python library xattr on venv/bin/xattr. Reason why I play with the PATH variable.

$ perl -T /usr/local/bin/exiftool -XAttrFinderInfo  DSCF0075.JPG 
Insecure dependency in require while running with -T switch at /usr/local/bin/lib/Image/ExifTool.pm line 8885.
Insecure dependency in `` while running with -T switch at /usr/local/bin/lib/Image/ExifTool/MacOS.pm line 568.

$ perl /usr/local/bin/exiftool -XAttrFinderInfo  DSCF0075.JPG
Warning: Error running "xattr" to extract XAttr tags - DSCF0075.JPG

$ PATH=/usr/bin:$PATH perl /usr/local/bin/exiftool -XAttrFinderInfo DSCF0075.JPG 

$ PATH=/usr/bin:$PATH perl -T /usr/local/bin/exiftool -XAttrFinderInfo  -R smalltest/2004-06-05\ Londres\ +\ EuroDisney/DSCF0075.JPG 
Insecure dependency in require while running with -T switch at /usr/local/bin/lib/Image/ExifTool.pm line 8885.
Insecure dependency in `` while running with -T switch at /usr/local/bin/lib/Image/ExifTool/MacOS.pm line 568.

Yes, I think it's likely best to explicitly list the path of all external commands. Not doing so introduces a potential security vulnerability as an attacker could place malicious versions of any of those external commands in the path.

OK. But if he could do that, you've already lost the battle. :P

I'll use a full path for all of these.

OK. But if he could do that, you've already lost the battle. :P

True...but I suppose it's best not to make it easier for him/her. 😄

Not sure exactly how the permissions work with a perl subprocess but I imagine they inherit the permissions of the calling process. In that case, one possible vector is attacker can place something in your path because they've got your permissions then for some reason you do a sudo exiftool ... which gives the attacker escalation of privilege. A bit far fetched but it's likely still best to avoid calling what could be an arbitrary command.

This patch was implemented on Apr 7, 2022 in version 12.41

*cough*Apr. 7, 2022*cough*

blush

Thanks! Comment edited.

Phil

	my @xattr = `xattr -lx "$fn" 2> /dev/null`; # get MacOS extended attributes
	if ($? or not @xattr) {
	$? and $et->Warn('Error running "xattr" to extract XAttr tags');
	return;

call xattr with full path on macOS