Pseudo-Admin can't set System32 ACLs?

[Gerry Hickman]

Hi,

I have stand-alone clean install of Vista Business 32bit, all on
defaults, UAC is enabled.

I need to rename a file in System32 (long story), but my Pseudo-Admin
account only has read access, and it seems impossible to adjust the
permissions even after accepting the UAC prompt.

 

[Jimmy Brush]

Hello,

This is one way that Windows protects its core operating system components
from being modified (system file protection). Generally, the core Windows OS
files should only be updated during a service pack install, so by default
the permissions on the files are set such that this is the ONLY way they can
be updated.

However, as an administrator you can (of course) give yourself permission to
have read/write access to these files.

1) Take ownership of the file

- Right click file, click properties
- Click Security Tab
- Click Advanced
- Click Owner Tab
- Click Edit
- Click Administrators group
- Click OK
- Click OK to the message
- Click OK twice more to close out all properties dialogs

Now that you are the owner of the file, you can change the permissions on
the file even though you do not have explicit permission to do so. However,
you still can't modify that file - you have to give yourself that
permission.

2) Change the permissions

- Right click file, click properties
- Click Security Tab
- Click Edit tab
- Click Administrators group
- Click Full Control (or however much permission you need)
- Click OK to the message
- Click OK
- Click OK

Once you have modified the file to give yourself more permissions, it is
good practice to remove those permissions so that the administrative
programs that you run do not have access to those files (since they don't
need this access).

 

[Gerry Hickman]

Hi Jimmy,

Ok, the real question is therefore about ownership. It would appear
there's a similar issue with "Program Files" and probably some others.

It would seem huge numbers of files are not fully accessible to the
genuine Administrator of the computer. They are owned by "Trusted
Installer" and I'm guessing you can't log in as that.

On my SERVERS, every file has full access by the Administrators group,
but not the Adminitrator account (unless it's a member which is usually
is). During server migrations I've had to use CACLS against EVERY file
on a big server. In client disaster recovery scenarios I've had to
replace things like ntoskrnl when it was corrupt. In longhorn, the
ownership will probably be like Vista.

On CLIENTS I guess it's not so important, you just FDISK and start
again, but I don't like the look of this. I think it could be used
against the legal owner of the machine.

 

[Guest]

It would seem huge numbers of files are not fully accessible to the

genuine Administrator of the computer. They are owned by "Trusted
Installer" and I'm guessing you can't log in as that.

TrustedInstaller is a service. And you are correct, you can't log in as that.

On my SERVERS, every file has full access by the Administrators group,
but not the Adminitrator account (unless it's a member which is usually
is). During server migrations I've had to use CACLS against EVERY file
on a big server. In client disaster recovery scenarios I've had to
replace things like ntoskrnl when it was corrupt. In longhorn, the
ownership will probably be like Vista.

There is nothing stoping you for performing these tasks on Vista. It just
takes an extra step (you have to take ownership and then change permissions).

On CLIENTS I guess it's not so important, you just FDISK and start
again, but I don't like the look of this. I think it could be used
against the legal owner of the machine.

I don't see how, since you can still access those files.

- JB