codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 19, 2016, at 02:52, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote:
> 
>>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is emptied at boot.
>> 
>> No.  /tmp is emptied at boot, not /var/tmp and not /var/folders.
> 
> Did that change after 10.9? I keep a Finder window open on $TMPDIR on one of my "Spaces", and it's always empty after logging in to a new session (which I only do after rebooting).

I could just be wrong.  I'll double check tomorrow.

/var/tmp definitely isn't cleared though.

>> Well, if you're able to update to 10.10+, launchd2 is much much nicer at helping triage such things...
> 
> At some point I guess I will... (have to...)
> 
>> There are ACL settings somewhere to control that.  It's not based on uid.  I don't recall what it is off the top of my head.
> 
> OK, great, let me know if anything comes to mind that could help me in a google search.
> 
>>> , and when?  Boot time? Or login, and if so, what kind of login?
>> 
>> The user (background) session is created whenever the user does pretty much anything (ssh, cron, sudo -u, screen sharing, etc.).
>> The gui (aqua) session is created wheneger the user logs in to the gui (screen sharing, console, etc).
>> 
> 
> And the gui session is never taken down when the user logs of the gui?

It is at some point.

> Should one think of launchd as the equivalent of Linux's systemd, or does it also have bits of DBus?

Similar in concept I suppose but quite different in practice.

I'd take launchd over DBus and systemd any time.

> 
>> iconservicesagent processes? 2, one in the system domain and one in my user's aqua session:
>> $ ps aux | grep iconservicesagent
>> jeremy            677   0.0  0.1  2918544  19908   ??  S    Mon09AM   0:08.85 /System/Library/CoreServices/iconservicesagent
>> root               92   0.0  0.0  2516172    492   ??  Ss   Mon09AM   0:00.47 /System/Library/CoreServices/iconservicesagent
>> 
> 
> How large is root's icon cache? Do you have any idea why the agent is running for root? Because of the login manager, maybe?

It's in the system session, not root's user session.  That's the LaunchDaemon.

>> Yes.  That's a clear privacy violation.  User A could use that to determine what applications User B has installed.  If there happened to be some kind of image rendering exploit, User A could install an app private to them to cause User B to render compromised icons.  Etc, etc, etc.
> 
> And you're seriously thinking that user A couldn't figure that out otherwise, like from looking at the output from ps (running ps in a cron job because evidently no 2 users can be logged in to the gui at the same time).

ps would only tell you what is running, not what is installed.

User B should also not have their icon sets changes just because User A downloaded some. ew app.

> Even if keeping track of who's entitled to access which bits of cached icon info the cache agent could prune the cache, removing everything that hasn't been accessed for more than a reasonably long time.

Again, I think you are seeing something anomalous.  You should investigate before jumping to conclusions.

>> Have you looked at the cache to see exactly what the icons are that are taking up so much room?  I suspect that might give you a clue as to how they're getting there in the first place.
> 
> Well, I did take a look, but there' a LOT of files in there, and they all seem to be quite small. That's backed up by the percentages in brackets from afsctool; those are CPU loads. With 4 threads that should approach 400% if there were only large files; the smaller the number, the more time the algorithm spends waiting for I/O instead of compressing data.
> 
> R.
> 
> PS: 
> Aqua, seriously? Is that term still being used or is it just a hardcoded string in a couple of places that was never changed? Because there isn't much left of the original watery appearance; possibly only the default selection/highlight colour ... :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160919/0198805a/attachment.html>