"Enable-Private-Data" in a command line application ..

The logging from my command line app is all generated from an embedded library. That same library when used in a *.app context, with the same log-behavior-modifying Info.plist directives, renders private items publicly, as expected .. bafflement ensues!

A minimal command line app is exhibiting the same unexpected behavior, and there's not much left to make mistakes in.

Hopefully, someone will point out an appallingly simple error, else, I'll wrap this up into an FB.

Source

import Foundation
import OSLog

let loggingTest = Logger(subsystem: "com.ramsaycons", category: "LoggingTest")
loggingTest.log("info: \(Bundle.main.infoDictionary!)")

Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>OSLogPreferences</key>
	<dict>
		<key>com.ramsaycons</key>
		<dict>
			<key>DEFAULT-OPTIONS</key>
			<dict>
				<key>Enable-Private-Data</key>
				<true/>
			</dict>
		</dict>
	</dict>
</dict>
</plist>

Xcode run output (whitespace modified for readability):

info: [
"DTPlatformBuild": , "LSMinimumSystemVersion": 14.5, "DTXcode": 1540, 
"CFBundleSupportedPlatforms": <__NSArrayM 0x600000e58720>(MacOSX), 
"DTSDKName": macosx14.5, "DTCompiler": com.apple.compilers.llvm.clang.1_0, 
"DTXcodeBuild": 15F31d, "DTSDKBuild": 23F73, "DTPlatformName": macosx, 
"DTPlatformVersion": 14.5, "BuildMachineOSBuild": 23F79, 
"OSLogPreferences": {
    "com.ramsaycons" =     {
        "DEFAULT-OPTIONS" =         {
            "Enable-Private-Data" = 1;
        };
    };
}]

Program ended with exit code: 0

Console.app output:

default	17:16:33.869184-0400	LoggingTest	info: <private>

I would classify this as a bug, and I encourage you to file a bug report about it. Please post your bug number, for the record.

But, just for fun, lemme explain what’s happening here…

The system log API exists below Foundation. That makes sense when you think about it: Foundation needs to be able to call the system log API, at a minimum in order to implement NSLog.

That means that the system log API can’t use NSBundle. Instead it has its own bundle wrangling code [1]. AFAICT that code doesn’t have the smarts to recognise the __TEXT / __info_plist section, and that means that the system log can’t find the OSLogPreferences property in that section.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Actually, it relies on XPC for this [2]. XPC has to have its own bundle code for similar reasons.

[2] The low-level XPC implementation, not NSXPCConnection. The latter is part of Foundation.

Thanks, Quinn, for the explanation; I like the "for fun" stuff .. it makes perfect sense, and is a little obvious after the fact!

In passing, I'll mention finding another way of defeating <private> (which I won't be explicit about, though it's not too hard to find). Dropping a particular plist file into a particular /Library/Preferences/.. location enables opening <private> for a command line app (and everything else). It's not useful to me (and neither is the config profile) because I need to ask someone else, with a wider range of models of the hardware I'm working with), to run my program. I won't ask someone else to open global holes in their security .. an app-local solution which only opens <private> for that one app and only for the duration of its execution is essential. For my immediate need, I can wrap the command line into a trivial *.app.

I'll file a bug and report the FB# here ..

FB13802238

Dropping a particular plist file

Yeah, that’s pretty much equivalent to the configuration file approach that I reference in Recording Private Data in the System Log.

FB13802238

Thanks!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"