I wonder if this is social engineering along the same vein as the xz takeover? I see a few structural similarities:

• A lot of pressure being put on a maintainer for reasons that are not particularly obvious what they are all about to an external observer.
• Anonymous source other than calling themselves KA - so that it can’t be linked to them as a past contributor / it is not possible to find people who actually know the instigator. In the xz case, a whole lot of anonymous personas showed up to put the maintainer under pressure.
• A major plank of this seems to be attacking a maintainer for “Avoiding giving away authority”. In the xz attack, the attacker sought to get more access and created astroturfed pressure to achieve that ends.
• It is on a specially allocated domain with full WHOIS privacy, hosted on GitHub on an org with hidden project owners.

My advice to those attacked here is to keep up the good work on Nix and NixOS, and don’t give in to what could be social engineering trying to manipulate you into acting against the community’s interests.

Most of mine are variations of getting confused about what system / device is which:

• Had two magnetic HDDs connected as my root partitions in RAID-1. One of the drives started getting SATA errors (couldn’t write), so I powered down and disconnected what I thought was the bad disk. Reboot, lots of errors from fsck on boot up, including lots about inodes getting connected to /lost+found. I should have realised at that point that it was a bad idea to rebuild the other good drive from that one. Instead, I ended up restoring from my (fortunately very recent!) backup.
• I once typed sudo pm-suspend on my laptop because I had an important presentation coming up, and wanted to keep my battery charged. I later noticed my laptop was running low on power (so rushed to find power to charge it), and also that I needed a file from home I’d forgotten to grab. Turns out I was actually in a ssh terminal connected to my home computer that I’d accidentally suspended! This sort of thing is so common that there is a package in some distros (e.g. Debian) called molly-guard specifically to prevent that - I highly recommend it and install it now.
• I also once thought I was sending a command to a local testing VM, while wiping a database directory for re-installation. Turns out, I typed it in the wrong terminal and sent it to a dev prod environment (i.e. actively used by developers as part of their daily workflow), and we had to scramble to restore it from backup, meanwhile no one could deploy anything.

more is a legitimate program (it reads a file and writes it out one page at a time), if it is the real more. It is a memory hog in that (unlike the more advanced pager less) it reads the entire file into memory.

I did an experiment to see if I could get the real more to show similar fds to you. I piped yes "" | head -n10000 >/tmp/test, then ran more < /tmp/test 2>/dev/null. Then I ran ls -l /proc/`pidof more`/fd.

Results:

lr-x------ 1 andrew andrew 64 Nov  5 14:56 0 -> /tmp/test
lrwx------ 1 andrew andrew 64 Nov  5 14:56 1 -> /dev/pts/2
l-wx------ 1 andrew andrew 64 Nov  5 14:56 2 -> /dev/null
lrwx------ 1 andrew andrew 64 Nov  5 14:56 3 -> 'anon_inode:[signalfd]'

I think this suggests your open files are probably consistent with the real more when errors are piped to /dev/null. Most likely, you were running something that called more to output something to you (or someone else logged in on a PTY) that had been written to /tmp/RG3tBlTNF8. Next time, you could find the parent of the more process, or look up what else is attached to the same PTS with the fuser command.

Lemmy instances are no different to any other website, in this regard. To ‘take over’ an instance would be to take over hosting of a website - which would mean either re-pointing the DNS somewhere else (and getting a copy of the database), or to take over the hosting of it (e.g. if it is hosted with a cloud provider, or you are physically taking possession of the hardware).

Taking over the DNS in nearly any gTLD or ccTLD (short of some kind of compromise at least) generally requires one of the following: 1) a process initiated by the registrant, or 2) proving that you are the registrant, or 3) proving you owned the trademark in the domain before it was registered or 4) waiting until the domain expires, any grace period is up, and then being first to register the domain.

If the admin is completely gone, and they are the individual owner of the instance, you could wait for (4) and try to drop-catch the domain. But domains are generally registered for a minimum of 1 year, and often up to 10 in advance, so it could be a long wait. And even then, you wouldn’t have a copy of the database. It is quite possible the actual hosting of the instance has not been pre-paid for anywhere near that long (or might fail in any number of ways, or fall out of date and get compromised, or need some kind of manual intervention following a problem), so it could go down and not come back up a long time before the domain name expires.

If the admin has made same arrangements in advance for takeover of the instance in case they are unable to continue, the picture can be a lot better. They might, for example, if they created a legal structure (company, not-for-profit organisation) for the instance, and that is the registrant and owner of cloud resources etc…, then maybe other members of the organisation could call a Special General Meeting (or whatever similar procedure the org’s rules set up in advance say), appoint a new president, and then the new president can prove their authority to any providers involved to get access to the organisation’s resources (e.g. hosting server). Or maybe they could set up a dead-man’s switch system to automatically email credentials for all the resources if they don’t check in for a couple of weeks; or give a few trusted people the credentials (possibly encrypted with something like Shamir’s Secret Sharing to ensure n of m trusted friends - e.g. any 7 of 10 or something, need to combine their secrets to get the credentials) to take over the instance. But any of those things would require they have planned for that eventuality in advance.

Otherwise, of course, all users of the instance could just chose another instance (possibly posting a last message with a public key to that instance, to establish the link to their new account).