Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

Post reply on HN
Print view View original

521–530 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#521

Post by fomine3 »

brap wrote: post #491
highwaylights wrote: post #159

Earlier quoted context omitted.

I don't think any major desktop OS handles this well. I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. macOS comes pretty close to what I'd ideally want i…

iOS is the gold standard IMO. Apps are sandboxed, can only interact with the outside world via APIs (that the user needs to approve), one click uninstall and it’s all gone without a trace (at least in theory). Love it.

I think Android does it better with third party store and sideload support. It seems that iOS depends some security to their own the AppStore. (example: disallow dynamic code generation like JIT)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#522

Post by eru »

NoZebra120vClip wrote: post #288
eru wrote: post #236

Earlier quoted context omitted.

Yes. But if you stick everything into a single .exe, the user can't interfere.

> Yes. But if you stick everything into a single .exe, the user can't interfere. Alright cowboy, so where are you storing preferences and settings?

Well, you stick that in some user directory that would stick around even after a 'normal' uninstaller runs.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#524

Post by saagarjha »

_hao wrote: post #45
el_benhameen wrote: post #2

Any time I see a Microsoft link with a cheeky title, I assume it’s a great Raymond Chen deep dive. Haven’t been wrong yet!

As an aside every time I come across a Raymond Chen article I remember this post from Joel Spolsky - https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... I remember very distinctly this quote about him: > The only person in the world who leapt to my defense was, of course, Raymond Chen, who is, by the way, the best programmer in the world, so that has to say something, right? So in my mind I've made the co…

This is an interesting article, because it's a product of its time: modern languages solve a lot of these exact problems. I think this is a resounding success that they have correctly identified a genuine problem that people used to struggle with (safe types, exceptions) and make it standard and correct and ergonomic.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#525

Post by TheHappyOddish »

grishka wrote: post #269
TheHappyOddish wrote: post #246

Earlier quoted context omitted.

I'm fairly sure Android apps running as root (like this driver installer probably was) will also have access over all files without asking. That's the danger of root.

Android apps themselves can't run as root. The apps that do perform operations "as root" do so by spawning a shell process running as root, usually using `su -c`. That's on a rooted device. Normally, all privileged actions are done by system daemons that run with appropriate permissions and that apps communicate with through the "binder" IPC mechanism. Those daemons also handle access control — both the regular Andro…

Thanks for the explanatin, I'd never looked into it.

> The apps that do perform operations "as root" do so by spawning a shell process running as root, usually using `su -c`. That's on a rooted device.

So in a scenario like what we're discussing here (a dev deciding to build an uninstaller their own way), on a rooted device (as per the GP's context of "this coming to Linux and Windows"), the app in question could still run as root, and this permission set from Android would solve nothing?

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#526

Post by danbruc »

crabbone wrote: post #518
Arch-TK wrote: post #323

Earlier quoted context omitted.

I think maybe you should familiarise yourself with how e.g. ext4 works. You can unlink a file and have a process still hold a reference to the inode. This allows you to continue reading (or executing) a file which may not have been fully mapped yet even after its last filesystem reference is gone. There really isn't that much of a good reason to disallow deleting the files (assuming NTFS is capable of supporting a si…

1. I know how Ext4 works in this case, and I don't care. 2. I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it. 3. Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface). Process doesn't get a reference to the file from which its executable code is loaded at all…

I know how Ext4 works in this case, and I don't care.

I think the comment to learn about Ext4 was aimed at me.

I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it.

As I explained before, Windows - and also Linux - made the reasonable decision to back the memory of a process with the executable file so that the memory can be easily paged in and out. This decision forces you to make the executable file non-deletable while the process is running.

This is true for Windows and Linux, neither of them will delete the executable file while the process is running. Some file system including Ext4 and NTFS support initiating a delete while the file is still in use, which will make the file look deleted and eventually also delete the file. But this does not truly delete the file until the process exits, i.e. you can not reuse the disk space of the executable file immediately.

So depending on what you want from deleting the executable file while a process is running - do you only want it to look deleted and eventually disappear or do you want to reuse the space of the executable file - the file system might give you what you want even if processes are backed by their executable files. Or it might not.

Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface).

It would of course be a bad idea if processes would know about inodes, that is an implementation detail and not all file system use inodes. That does however not mean that processes can not hold references to inodes, a file descriptor is a reference to some file which will be implemented as a reference to an inode for Ext4.

Process doesn't get a reference to the file from which its executable code is loaded at all (unless you count the first argument -- but that's the file's name, not the file).

The process does not get that reference but the executable file is loaded as a memory mapped file, so the virtual memory manager will have a file descriptor for the executable file and indirectly reference an inode on file systems using them.

I want this power to delete the executable file as it's being executed. I see no reason not to have such power.

You can have this if you give up loading executables as memory mapped files. Or, if it is good enough for you that the file looks deleted and eventually gets deleted but the disk space does not become reusable until the process exits, if you use a file system that supports deleting open files.

Take some embedded system, you habe 4 MiB RAM, 8 MiB flash, 7 MiB executable. The only way to run this executable is by loading it as a memory mapped file, you can neither load it completely into memory nor can you create a big enough swap file.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#527

Post by mike_hearn »

ripley12 wrote: post #493
RajT88 wrote: post #414

Earlier quoted context omitted.

Can confirm. I would be considered by most to have been a Windows Installer expert at one point. Installshield / Wix / Whatever else. It is intentionally obtuse at times (MSIFileHash table uses rearranged MD5 hashes for example), and also many features made sense for the late 90's/Early 2000's era where bandwidth was low and connectivity limited, and lots of stuff was distributed on CD's. The look on people's faces w…

> It was deprecated by the newer AppX/MSIx/AppV format which uses sandboxes, binary chunks/streaming and no executable code to install stuff. I can offer a little perspective on MSIX, having devoted months of my life to it in a past job. MSIX is nearly unusable outside the Store. It will work in a tightly controlled environment, but when you try to deploy it to a wide variety of users you will run into 1) unhelpful e…

MSIX can be made to work in that context. We've done it, although it required writing our own installer EXE stub that invokes the package management API rather than using Microsoft's own "App Installer" app, and doing lots of remote diagnosis to solve the mysterious bugs you were hitting. I would indeed not recommend anyone try to use it with Microsoft's own tooling.

Still, when you finally make it work you get a lot of benefits. MSI is clearly dead end tech which is why so many MSIs are just installer EXEs wrapped in the file format. It doesn't have any clear path to modern essentials like online updates, keeping the OS clean, sandboxing and so on. If you were on the Windows team, what would you say the future was?

For enterprise environments it's actually somewhat the opposite: MSIX packages can be installed without admin privileges due to their declarative nature, and it's very easy for admins to provision MSIXs to Active Directory groups because they don't have to do any repackaging work. Yes, some admins have hacked Windows to stop it working because when MS launched the Store they didn't provide any way for admins to opt out, but these days they have the knobs they need. Also, because they're just zips you can always just unzip them into your home directory to get at the app inside. It won't auto update that way, but as long as EXEs can run from the home dir it can work.

Products like Office and Visual Studio have entire teams devoted to nothing but their installers, which is clearly going too far in the opposite direction. Most products won't want to do that.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#528

Post by mavhc »

WorldMaker wrote: post #480
mavhc wrote: post #435

Earlier quoted context omitted.

As soon as Office 2007 didn't use MSI the format was doomed. I assume the Here in NIH refers to an individual team, not MS as a whole. Teams is entirely NIH https://github.com/Squirrel/Squirrel.Windows for updates to the Electron app. I would use winget, but MS made it weirdly hard to run as a script on multiple computers, it installs per user, because... who knows. So still using chocolatey

To be fair, Squirrel came from GitHub and early Electron before Microsoft bought GitHub, so it wasn't Microsoft's NIH that built Squirrel originally.

True, I used NIH in the opposite meaning accidentally, I mean it was not invented at Microsoft

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#529

Post by daemin »

devnullbrain wrote: post #389
daemin wrote: post #371

Earlier quoted context omitted.

Yes, that is what I mean by my last point: "It allows for portable installations and to run software just copied from other sources." You can think of decompressing from an archive as running a very simple installation program. If the only installer available was one provided by the OS how long do you think it would take to make that the only way to install and run software. These things are being done right now on m…

>If the only installer available was one provided by the OS There's the non-sequitur. OP never said that this is what should happen. It is strange to leap to this assumption while also wanting to define portable programs and archives as 'installers'. In the context of Windows, 'special' installers means the programs you run to be able to use a different program that don't appear on other OSes.

I did not define portable programs and archive extractors as installers, just suggested the act of decompressing to a directory or copying to a directory would be considered as installing the program.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#530

Post by nikanj »

sim- wrote: post #516

Imagine if Windows just allowed DeleteFile() even if the file was open, like unlink() on almost any other OS...

Imagine all the "WinBLOWZ is bullshit, I deleted 200 gigs of shit and my C: still has no more free space" posts if Windows started doing soft deletes
Post reply on HN