Kernel-level Explorer

O

OpenSource Ghost

Member
From what I understand, NTLite doesn't invoke any special privileges when editing images and instead uses deeper kernel-level access to do that. It would be nice to have a kernel-level explorer for users to make whichever manual adjustments they want without having to resort to 3rd party tools like NSudo and/or taking ownership of files/directories, which is a messy process and can ruin original ownership integrity. Kernel-level is more dangerous than permission/ownership adjustment, but it is also cleaner.
 
NTLite depends on DISM, which grants itself TrustedInstaller privileges from the TI service. Anything else you can do takeown/icacls.

The reason takeown/icacls is strongly discouraged for less technical users, is most people are careless and grant themselves rights but don't restore the original ownership when finished. For some files, it doesn't make a difference -- but for other critical system files, Windows breaks down because you (as the current owner) don't have the correct default rights to give the running process access.

Why don't you use PowerRun? If you want to run with scissors, that's up to you. I've seen enough horror stories where someone does takeown, and completely screws over their Windows. It may not happen to you, but it's a cautionary tale.
 
Taking ownership of registry entries can screw a system up too. Run elevated only when you need it.
 
OpenSource Ghost said:
From what I understand, NTLite doesn't invoke any special privileges when editing images and instead uses deeper kernel-level access to do that. It would be nice to have a kernel-level explorer for users to make whichever manual adjustments they want without having to resort to 3rd party tools like NSudo and/or taking ownership of files/directories, which is a messy process and can ruin original ownership integrity. Kernel-level is more dangerous than permission/ownership adjustment, but it is also cleaner.
Click to expand...
NTLite uses a (normal) elevated application level, not the kernel one.
It reverts any permission changes to the original after being done.
I agree it would be better to run as trusted installer, tried it once and didn't work, potentially would need to make a separate binary to run itself.
That's where it started looking hacky, and the current system works.
Using 3rd party binaries is not an option.

I know of users that start NTLite with those other tools as trusted installer.
If more users do that, until I manage to automate it, I could make a switch not to touch permissions.
 
Normally you can just explore mounted content and make your changes on it. Or you can simply open wim file via 7zip
 
nuhi You dont have control over issues and bugs in other peoples software. If i were to have an issue, you would have to investigate, contact the other devs, wait for a response and a fix(neither are guaranteed), if the tool handles it all entirely then any issue can be fixed a lot quicker.
 
Clanger said:
nuhi You dont have control over issues and bugs in other peoples software. If i were to have an issue, you would have to investigate, contact the other devs, wait for a response and a fix(neither are guaranteed), if the tool handles it all entirely then any issue can be fixed a lot quicker.
Click to expand...
Sure, but in this case it's just a task to start NTLite with TrustedInstaller impersonation, then it's smooth sailing.
The tool to start it as such is not having any input into the rest. Unless malicious, but that's another story and a reason why I would like to create my own.
 
Running NTLite under TI impersonation isn't a technical challenge. What my experience working with users (or even IT folks) taught me, is every time you make it transparently easy to override a built-in security feature, users will make faster mistakes.

Part of the logic for forcing UAC consent, or having to use PowerRun or NSudo, is constantly reminding users they have the power to cause serious trouble. There is a valid reason why those protections exist in the first place, and a less careful attitude is the biggest risk.
 
garlin said:
reminding users they have the power to cause serious trouble.
Click to expand...
Beginners are the worst, they remove the kitchen sink n all :rolleyes:.

"break something" every single removal/tweak will "break something" because it will not be as ms intended, the trick is knowing when to make acceptable compromises. I can break windows 10 to hell and back again and its still acceptable for my needs.
 
Last edited:
nuhi said:
Sure, but in this case it's just a task to start NTLite with TrustedInstaller impersonation, then it's smooth sailing.
The tool to start it as such is not having any input into the rest. Unless malicious, but that's another story and a reason why I would like to create my own.
Click to expand...

Would it be better to run NTLite while OS is in Safe Mode? Wouldn't it be easier for it to remove components and files when related services and/or drivers aren't running in the background. It may be a good alternative and minimize the need to use TI impersonation.
 
Clanger said:
Beginners are the worst, they remove the kitchen sink n all :rolleyes:.

"break something" every single removal/tweak will "break something" because it will not be as ms intended, the trick is knowing when to make acceptable compromises. I can break windows 10 to hell and back again and its still acceptable for my needs.
Click to expand...
I find learning and breaking taught me a lot with Ntlite. I just didn't go and ask every single thing and just learned not to touch that one when editing lol
 
OpenSource Ghost said:
Would it be better to run NTLite while OS is in Safe Mode? Wouldn't it be easier for it to remove components and files when related services and/or drivers aren't running in the background. It may be a good alternative and minimize the need to use TI impersonation.
Click to expand...
This has nothing to do with background services.

When Windows image files are extracted from the WIM, or installed on the live system, they have default security permissions as defined in the package manifests. TI-owned contents only give read/execute rights to Administrators, and by design no write privileges.

The whole point of requiring extra effort is to create awareness of your actions in wanting to manage those files. Anything you add to a product to hide this restriction makes you less careful in the long run.
 
Standard user accounts should be limited to modifying HKCU entries only because if you completely mess up one user account you can create a new one then delete the messed up one. Messin around = PEBKAC = great teacher.
 
Last edited:
You must log in or register to reply here.
Back
Top