Sent from my iPhone...
> On Sep 19, 2016, at 02:52, René J.V. Bertin <rjvber...@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.
> 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