Sent from my iPhone...
> On Sep 19, 2016, at 02:52, René J.V. Bertin <[email protected]> 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 [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
