Certificate trust policy not saving after account change

For anyone who might encounter this problem, here is how we eventually resolved it. Whatever corruption happened, it was not in the user folder (/Users/useraccount), but somewhere in the system-level data for that user. We deleted the account with the option to keep the user folder; this renames the folder to "/Users/useraccount (Deleted)". Then create a new user with the same username. (Of course made a backup first.)

It probably would work to take the option to restore from the "(Deleted)" folder, but since we weren't sure, we gave the new account ownership of the old directory and manually copied the contents. This included removing the new subfolders from the new ~/Library folder and copying the contents from the old account. The main difficulty with this route was fixing ownership permissions, because the files in the old account now have weird custom ownership through Access Control Lists (ACLs).

The ACL attributes which can be shown in Terminal with a '-e' option to 'ls'. For example:

% ls -le

-rw-r-----@ 1 username1 staff 2665 Jul 29 18:02 .bashrc

0: group:everyone deny delete

1: user:username1 allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

2: user:ITAdmin allow read,readattr,readextattr,readsecurity

The 0/1/2 can be removed with 'chmod -a' (see the man page). Symbolic links have to be done separately with the '-h' option.

The Terminal doesn't have access to some folders in ~/Library, but one way around that is to enable ssh access and simply 'ssh localhost'. The ssh session can access all the subfolders. Presumably this is a small roadblock to help users not accidentally do something catastrophic in the Terminal.

Long story short: Back up, delete the account but keep the directory, then create a new user and assign the old account directory. (Or go the more painful route and create the new user and manually copy data from the old account to the new. That was our option, but in retrospect the easier method should have worked, too.)

I did talk with a specialist yesterday, and the problem seemed to be a new one. Best guess is some kind of corruption in the user account. But no idea what exactly. I tried making trust settings in another account, then exporting (command line). I can import successfully to a third account, but for the problem account there is an error:

blitz:~% security trust-settings-import /Users/Shared/trustset 

[dialog box opens; enter password]

SecTrustSettingsImportExternalRepresentation: unknown error 13=d

Seems like an obscure failure with no error code?

Running the same command with 'sudo' claims to be successful, but Keychain Access doesn't show any change to the trust settings.