Sent from my iPhone...

> On Sep 19, 2016, at 02:52, René J.V. Bertin <> 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 ... :)
macports-dev mailing list

Reply via email to