Currently, if you are admin you are able to delete the instance.actor user. I just tested this (https://sk.foopool.de/notes/9x3sycm30p3e000g), and it seems to impact federation with instances that have authorized fetch enabled.
IMHO It should not be possible to delete a vital system user.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
I would find it weird when the import is always going to be CreateSystemUserService when the sole purpose of the import is only to get a function called "isSystemUser" as this imo just doesn't really match with each other
I was looking into this and it also is weird that instance.actor is declared multiple times in the code. Uh yeah checking for a dot should be fine as its not allowed in any user created account unless force inserted or changed from the DB
Ideally yes, it should be perfectly fine to check if the username is exactly equal to instance.actor. Misskey (and by extension forks of misskey) have preserved usernames and since the instance actor is already an existing user it's not as though someone can maliciously register an account under instance.actor (local or remote). Anyone abusing instance.actor as a personal account or to post unsavory things deserves a defederation in my opinion (we all have the expectation that instance.actor is a service account). I would be fine with a quick check. As for places that can't really be implemented, we can do a check on the id (we should have our actor stored in the database after all, along with remote instance actors). Shouldn't be too hard to implement safety checking for endpoints such as /api/admin/reset-password /api/admin/suspend-user on the expected userId parameter.
To add to this conversation, the consequences of deleting the local instance actor cannot be overstated. I am unsure if deleting an account causes the instance to issue a deactivation on the actor's keys (it does this for suspensions). I do know that considering how suspension of a local account ends up "deactivating" the actor and federating that deactivation if one was able to suspend the local instance actor (no, I am not doing that, even for testing purposes as it will burn the domain - I know we can suspend remote actors).
I have not seen how misskey does instance <-> instance federation; however, I have watched akkoma <-> mastodon-glitchsoc, the first thing it does to establish federation is a GET @instance.actor, exchanging keys. If this process is interrupted neither instance is able to federate. In my specific case, I was debugging a wireguard issue (MTU size ended up snowballing into an HTTP timeout on this specific fetch). Authorized fetch is not that big of a deal (instances have it disabled all the time) but not being able to establish an instance's "identity" because it's tied to the key of the instance actor?
That obliterates federation and there's no recovery from that. Other Misskey (and forks) instances might be able to reactivate the instance.actor user, but akkoma and plemora will not. I have seen this time and time again when issuing suspensions for local instance users, the second they get unsuspended all of the sudden accounts from *oma instances such as labyrinth.zone are unable to interact or engage at all until a manual override by the remote instance administrator.
The tested side effects of suspending a remote instance actor:
No report forwarding
My theorized side effects:
Complete breakage of remote lists containing users on our local instance (the instance actor is the default proxy account if I remember correctly)
Complete breakage of authorized fetch (retrieval from us, because the instance's key is tied to the actor's key)
Perhaps it would be better if we denied the ability to enter moderation menu at all for instance.actor regardless of host. If people want to block forwarded reports from remote instances there should be a separate menu, suspending the remote instance actor to accomplish that is not a valid workaround. Personally, in my library I am adding proper safeguards in place. Instance actors are of type RestInstanceActor which has overrides for SilenceAsync() and other functions that throw an InvalidOperationException()
publicoverrideTaskAcceptFollowRequestAsync()=>thrownewInvalidOperationException("You cannot accept a follow request from the instance actor");publicoverrideTaskRejectFollowRequestAsync()=>thrownewInvalidOperationException("You cannot reject a follow request from the instance actor");publicoverrideTaskCancelFollowRequestAsync()=>thrownewInvalidOperationException("You cannot cancel a follow request to the instance actor");publicoverrideTaskSilenceAsync()=>thrownewInvalidOperationException("You cannot silence the instance actor");
I would prefer if the API itself also had safeguards (BAD_PARAMS) for doing operations like /api/admin/delete-account
Could you try forwarding a report to my instance (sk.foopool.de)?
Because I restored a backup after the deletion, and authorized fetch started working again. So I guess either
the other instances just discarded the deletion of my instance.actor
sharkey did not actually send a deletion for the instance.actor
Sorry, let me clarify. Report forwarding is interrupted when it is inbound from the remote instance that you have suspended the actor of. I did notice that once you unsuspend the remote instance actor reports generated when it was suspended are not forwarded.
As for your bullet points, there's actually an easy way to tell. Do a POST request with the following payload
{"userId":"insert_actor_id"}
to your instance's baseurl/api/admin/reset-password. A curl command for this would be
Doing this will allow you to log in as the instance actor, what you can do from there is up to you but I have a couple of recommendations.
Make a couple of (public!) posts
Reply to a couple threads on akkoma instances. I have a labyrinth.zone account I could use to see if I can fetch your replies and posts on an *oma instance.
Delete the actor again (after backing up preferably)
What will happen is if sharkey is sending deletion for the instance actor, you will end up seeing a spike of outbound federation traffic as it issues a DELETE for each individual note you created in step 1 & 2. Due to current limitations of the code base, this is not rate limited and it should be instant to all instances the account federated with. This is probably grounds for another github issue (because on accounts with 20k+ notes I've watched it grind instances to a halt with 100% cpu utilization completely unresponsive until all deletion jobs are completed) but in this specific case we desire this behavior.
I'll try that.
Logging in as instance.actor works on the web interface as well: in the admin interface, select the instance.actor and click "reset password". Then in a private window, do inspect element on the login mask, and modify the pattern to include ..
Then just log in as you would normally. (connected issue: #628)
Thank you! This will give us a lot of information.
We will know whether sharkey (and by extension probably upstream misskey) follow through with account deletion on the instance actor.
We will know whether other instances respect the account deletion of the instance.actor (they'll probably respect the note deletions but as for the actual account that's on the table)
We will know whether the account deletion process deactivates an actor's keys.
The instance.actor as followrequests enabled by default.
And my mastodon gave an error 503 failed to fetch remote data while trying to follow the actor the first time