> On Sep 19, 2016, at 00:34, René J.V. Bertin <rjvber...@gmail.com> wrote:
> On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
>>>> Yes, of course it's possible.  Don't.  There's nothing special about the 
>>>> UID in this case that has anything to do with what you're seeing.
>>> So what does make the difference?
>> What is "the difference" that you want?  All users have a user session, and 
>> if logged in to the gui, they also have an aqua (gui) session.  All users.
> As I said, there's an order of magnitude difference in the size of the icon 
> cache for users like root, and that of users like macports or ldap.

Well, that has nothing to do with the username or uid.  It has to do with what 
the user is doing.

> 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.

> My machine has been up for 35 days, and in that time I certainly didn't log 
> any of the "incriminated" users into an aqua session.

Well, if you're able to update to 10.10+, launchd2 is much much nicer at 
helping triage such things...

> I did things as the macports user that could explain why an IconServiceAgent 
> was started for it, but that's it. FWIW, I removed the entries for a few 
> other users before reporting here, including avahi - those haven't come back 
> yet.
> A difference I could think of is a setting that tells the system not to let a 
> particular user log in to a gui session.
>  Which is why I thought of a UID<500; those at least don't show up in the 
> login manager. But maybe they can still be logged in if the login manager is 
> in traditional text (= no icon) mode?

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.

>>> Possibly a tool, but what could have that effect? AFAIK the icon cache is 
>>> chiefly used by the Finder, so anything that leverages the Finder might 
>>> cause an icon cache to be populated.
>> It's marked as RunAtLoad on my system (Sierra).  That would explain why it's 
>> running, even if nothing needs it...
> But RunAtLoad for whom

For all users.

> , 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).

> How many copies do you have running now?

Of what?

User domains?  11:
$ launchctl print system | grep com.apple.xpc.launchd.domain.user

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 
root               92   0.0  0.0  2516172    492   ??  Ss   Mon09AM   0:00.47 

> What surprises me is that every user would have to need a personal icon cache 
> for every icon in the system.
> I know user A could have an app installed with a doc type having a particular 
> icon that no other user on the system is likely to encounter, but would it 
> hurt if they did get to see the icon if they stumbled across such a document? 
> IOW, would it be bad if all file-to-icon associations were cached in a 
> central location, 1 copy for everyone?

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.

> Not only does that cache get big, it also consists of plenty of small files, 
> which makes its actual footprint on disk even larger (due to blocksize; I 
> think that hasn't changed with SSDs?).

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

macports-dev mailing list

Reply via email to