[SOLVED] You need permissions from ( S 1 5 ... )

UknownGuest

BANNED
Jun 7, 2020
28
0
40
Some files on my Computer, aswell as some temporary files are unable to delete even as "administrator account"

Registry Directory: Computer\HKEY_USERS
Default
S-1-5-18
S-1-5-19
S-1-5-20
S-1-5-21-3544183828-1212923669-2187502216-1001
S-1-5-21-3544183828-1212923669-2187502216-1001_Classes


What are those accounts and why are they installed on my machine?
I asume the ending numbers stand for the years 2018 - 2021.
Then what does this number stand for 3544183828-1212923669-2187502216-1001 ?
What does Classes stand for ?
 
Solution
I dont have full knowledge of the whole kernel level code, timings, and what it is doing, never will.
I like expirementing with my pc and the operating system, Sir you dont take any consequences if anything goes wrong, only me.

" I am the owner of my PC, but not fully... unless i really have control over it "
Yes, you are the "owner" of your system.

But there are things going on behind the scenes.
Just like your phone, your car, your TV, your router, etc, etc, etc.

Code security depends on permission levels.
Let's postulate 2 permission levels behind the scenes. "TrustedBlah" and "KernalFoo".

TrustedBlah is the one and only thing that is able to access '$Thing'.
KernelFoo needs some info from $Thing. It asks TrustedBlah for...

USAFRet

Titan
Moderator
Do you have knownledge how to gain access to the "above admin" accounts, if you would share this information..
No, you don't.

The system and OS does things outside of the realm of "user". Giving a user account permissions to that may prevent the function from accessing what it needs to be doing. Killing the actual operation of the system.

"Oh, I can fix it" you might say.
No...unless you have full knowledge of the whole kernel level code, timings, and what it is doing, you don't.
 

UknownGuest

BANNED
Jun 7, 2020
28
0
40
No, you don't.

The system and OS does things outside of the realm of "user". Giving a user account permissions to that may prevent the function from accessing what it needs to be doing. Killing the actual operation of the system.

"Oh, I can fix it" you might say.
No...unless you have full knowledge of the whole kernel level code, timings, and what it is doing, you don't.

I dont have full knowledge of the whole kernel level code, timings, and what it is doing, never will.
I like expirementing with my pc and the operating system, Sir you dont take any consequences if anything goes wrong, only me.

" I am the owner of my PC, but not fully... unless i really have control over it "
 

USAFRet

Titan
Moderator
I dont have full knowledge of the whole kernel level code, timings, and what it is doing, never will.
I like expirementing with my pc and the operating system, Sir you dont take any consequences if anything goes wrong, only me.

" I am the owner of my PC, but not fully... unless i really have control over it "
Yes, you are the "owner" of your system.

But there are things going on behind the scenes.
Just like your phone, your car, your TV, your router, etc, etc, etc.

Code security depends on permission levels.
Let's postulate 2 permission levels behind the scenes. "TrustedBlah" and "KernalFoo".

TrustedBlah is the one and only thing that is able to access '$Thing'.
KernelFoo needs some info from $Thing. It asks TrustedBlah for that particular data.
TrustedBlah reports back. "OK, but there is also 'UnknownGuest' that has access to it."
KernelFoo rejects that as now untrusted, and may be malicious.
Poof...whatever you were wanting to do is now broke.

You can tilt against that windmill all you want, but that is the way things work.
 
  • Like
Reactions: UknownGuest
Solution

UknownGuest

BANNED
Jun 7, 2020
28
0
40
Yes, you are the "owner" of your system.

But there are things going on behind the scenes.
Just like your phone, your car, your TV, your router, etc, etc, etc.

Code security depends on permission levels.
Let's postulate 2 permission levels behind the scenes. "TrustedBlah" and "KernalFoo".

TrustedBlah is the one and only thing that is able to access '$Thing'.
KernelFoo needs some info from $Thing. It asks TrustedBlah for that particular data.
TrustedBlah reports back. "OK, but there is also 'UnknownGuest' that has access to it."
KernelFoo rejects that as now untrusted, and may be malicious.
Poof...whatever you were wanting to do is now broke.

You can tilt against that windmill all you want, but that is the way things work.

I understand, thanks for your help.