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

[Jeremy Huddleston Sequoia]

> On Sep 19, 2016, at 00:34, René J.V. Bertin <rjvbertin at 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
		com.apple.xpc.launchd.domain.user.235
		com.apple.xpc.launchd.domain.user.502
		com.apple.xpc.launchd.domain.user.200
		com.apple.xpc.launchd.domain.user.260
		com.apple.xpc.launchd.domain.user.55
		com.apple.xpc.launchd.domain.user.92
		com.apple.xpc.launchd.domain.user.501
		com.apple.xpc.launchd.domain.user.212
		com.apple.xpc.launchd.domain.user.89
		com.apple.xpc.launchd.domain.user.202
		com.apple.xpc.launchd.domain.user.0

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160919/600e3846/attachment.p7s>