Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Acces denied for Admins?


  • Please log in to reply
16 replies to this topic

#1
RacerBG

RacerBG

    Junior

  • Member
  • Pip
  • 61 posts
  • Joined 07-November 13
  • OS:XP Pro x86
  • Country: Country Flag

I don't know when this happened but for some reason if my friend is trying to mount some iso image or even to uninstall a program "acces denied" is shown. He have Admin account but still Windows 7 is refusing some mandatory tasks. What could be the problem?

 

PS: On my XP machine I haven't got a single problem about Admin rights.


banner-winxp-logo.gif



How to remove advertisement from MSFN

#2
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,282 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

Aside from "uninstall a program", what "mounting" software? Or are we supposed to guess?


Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#3
Tripredacus

Tripredacus

    K-Mart-ian Legend

  • Super Moderator
  • 9,814 posts
  • Joined 28-April 06
  • OS:Server 2012
  • Country: Country Flag

Donator

Some locations are protected or owned by other accounts. TrustedInstaller is one of these accounts that may own a directory, and show an Access Denied message even to an account with Admin rights.
MSFN RULES | GimageX HTA for PE 3-5 | lol probloms
msfn2_zpsc37c7153.jpg

#4
RacerBG

RacerBG

    Junior

  • Member
  • Pip
  • 61 posts
  • Joined 07-November 13
  • OS:XP Pro x86
  • Country: Country Flag

For example mounting an image with Daemon Tools and uninstalling is impossible not just for one program but for all programs.

 

TrustedInstaller sounds like...correct answer but I'm still not sure. And if this is the case how he (my friend) can bypass it?


banner-winxp-logo.gif


#5
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,868 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Easy! You must become TrustedInstaller! :P



#6
RacerBG

RacerBG

    Junior

  • Member
  • Pip
  • 61 posts
  • Joined 07-November 13
  • OS:XP Pro x86
  • Country: Country Flag

Interesting find. I will see what I can do about it.


banner-winxp-logo.gif


#7
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,868 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Please do keep us posted about how it develops.

#8
RacerBG

RacerBG

    Junior

  • Member
  • Pip
  • 61 posts
  • Joined 07-November 13
  • OS:XP Pro x86
  • Country: Country Flag

My investigation was short. The reason for this strange acces denied errors was Comodo Firewall which I installed a few weeks ago to protect his laptop from viruses. Strange but thanksfully correct answer. :)

 

Thanks anyway for the suggestions, guys.


banner-winxp-logo.gif


#9
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • Joined 12-May 07
  • OS:none specified
  • Country: Country Flag

Hey, at least you confirmed that the firewall did its job, even if it wasn't what you expected.  And I suppose there is a setting you can adjust so that COMODO allows the requested activity.

 

Cheers and Regards


Posted Image


#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,401 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Hey, at least you confirmed that the firewall did its job, even if it wasn't what you expected.  And I suppose there is a setting you can adjust so that COMODO allows the requested activity.

 

Cheers and Regards

To be picky, a firewall should be between you and a (possible) fire and not stand right in the middle of your office, preventing you to get to (say) the restroom or your co-workers' desks. ;)

In other words, it should be a safety measure against perils coming from the outside, not an obstacle to everyday work.

Maybe this round the good Comodo guys overdid it a little. :unsure: (or their "smart" Default Deny Protection is not as smart as one would expect :whistle:)

 

jaclaz



#11
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • Joined 24-September 07
  • OS:none specified
  • Country: Country Flag

Hey, at least you confirmed that the firewall did its job, even if it wasn't what you expected.  And I suppose there is a setting you can adjust so that COMODO allows the requested activity.
 
Cheers and Regards

To be picky, a firewall should be between you and a (possible) fire and not stand right in the middle of your office, preventing you to get to (say) the restroom or your co-workers' desks. ;)
In other words, it should be a safety measure against perils coming from the outside, not an obstacle to everyday work.
Maybe this round the good Comodo guys overdid it a little. :unsure: (or their "smart" Default Deny Protection is not as smart as one would expect :whistle:)
 
jaclaz


Hear hear. :thumbup: This nonsense they started quite a long time ago, pretty much around the time of mainstreaming OS and software from Win9x to WinXP. Many relatively tame programs in their "new" NT versions like Norton, McAfee, Flash, etc began to make ACL adjustments during setup. Perhaps it was even earlier during NT/NT4/Win2K, who knows, but it became noticeable during WinXP.

The problem is when you go to uninstall something that does this ( changes permissions on folders and registry keys ) there is little guarantee that the uninstaller will reset them back to the way they were before, even if they were so inclined do they really know what the permission should now be set at? It's not an easy task and naturally consumer Windows offers no simple method of auditing ACL's or saving their state, or resetting them. Consequently there are a million unexplained annoyances many of which are probably permission related.

This is one of the main reasons for the official "removers" from Norton and McAfee I believe, necessary to remove files and keys that mere mortals cannot. Flash still modifies several registry key permissions even today, with every single update even after you manually revert them to the way they were. Firewalls as Jaclaz says ( and all security software and everything else really ) should be a positive experience, a friendly tool, but there is no reason for them to be as we crossed the Rubicon of developer responsibility long ago unchallenged whenever they made these aggressive attacks on the user's very own computer. There is no semblance of responsibility or restraint, they do what they want. They don't even attempt to document what they have done, nor does it appear in many discussion threads.

The permission alteration issue is one of the moral cases, something that should be done "with permission" pardon the pun. It dovetails with another Rubicon that was crossed at the same time, programs that use the Internet at will ( phone home, or whatever ). This should never have been allowed to happen without permission as no-one will tolerate it in real life ( a guest visitor using the phone at will ). Another moral line crossed with hardly a whimper. Is there any wonder why malware is everywhere? It's almost hard to even call them illegal compared to what other software already does at will.

Back to the security topic, the only good solution IMHO is for someone to develop a comprehensive permissions auditing tool. One that records all of their states periodically and can do smart diffing, for example comparing all currently existing objects' ACL with their previous state but leaving out new ones and missing old ones and highlighting only changes. You can brute force record ACLs at two different periods in time but the diff comparison is almost unusable because of missing old ones and lots of new ones. Troubleshooting Windows is fast approaching needle-in-haystack probabilities.

... Let him who hath understanding reckon the Number Of The Beast ...


#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,401 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Well, just for the record, the good DELL guys managed to alter permissions even BEFORE installing the XP :w00t::

http://www.911cd.net...pic=15138&st=29

they IMHO deserve the first prize :yes:.

 

jaclaz



#13
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • Joined 24-September 07
  • OS:none specified
  • Country: Country Flag

A great experiment which I never did was to install Windows XP on FAT instead of NTFS. ( never wanted to deal with potential structural problems or huge disk limits ).

 

But it would be nice to test Windows XP without any ACL's mucking up the mix, not to mention hidden streams. I doubt it is possible but I figured you would know if there was a way to format NTFS without those particular metadata.

 

Of course, there may be some dependencies in Windows XP that crap out when that metadata does not exist. But if it were possible, I believe every transaction would see an immediate boost in speed due to absent permission checking on every read/write, not to mention non-file-I/O logic not wasting time with admin/standard permissions. That is the theory of course. No guarantee the good guys in Redmond considered writing dual-use code ( that is, dual file system compatibility ) it might run through the permissions functions anyway and return "not-NTFS" and save no time whatsoever.


... Let him who hath understanding reckon the Number Of The Beast ...


#14
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,868 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

I run XP strctly on FAT-32 since my 1st XP SP2 install in 2005. Never had any problem. :yes:



#15
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,401 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Sure, there is no problem in running XP in FAT32, Vista is possible, Windows 7 seemingly no, and not really because of the hardlinks, symlinks and junctions (though of course the size grows), but because of the stupid WinSXS, and the senselessly long stupid filenames:
http://reboot.pro/to...files/?p=182961
(the good news being that a Windows 7 on NTFS can be shrinked by hardlinking more stuff):
http://reboot.pro/to...rdlinked-files/


jaclaz

#16
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • Joined 24-September 07
  • OS:none specified
  • Country: Country Flag

Actually I wasn't clear. I knew about 2K/XP on FAT32, but just never felt like trying because of the inevitable disk limitations, and the lesser integrity from non-journaling and other safety valves.

 

What I meant was some way to create an NTFS system without $Secure, and to further the daydreaming - some way to eliminate streams also ( streams I am just biased against because of the concept of hiding stuff from the computer owner. )

 

The thing about ACL's is they are implemented in all-or-none fashion. I think a better idea would have been starting with a fresh naked NTFS space, no ACL's on any object, and only then adding them in for specific objects when wanted. Windows API should have used functions that first test for presence of ACL on an object and then efficiently fall through when absent, and only cycling through security procedures when they do exist. Unfortunate design choices in the early NT era I guess, because if in Windows functions ACL's are assumed to exist everywhere there is little to be gained by removing $secure from NTFS because Windows itself will still be doing the work as if they were there.

 

Presently we have the worst possible implementation IMHO, access control lists for every object ( file/folder/key ) and they must be consulted for every transaction, and of course are available to be tampered with by everyone at will, and there is no comprehensive tool to manage the chaos. However, ACL's created à la carte ( i.e., objects are clean by default, permissions only exist when intentionally specified ) would mean you could pull up a list of all ACL's ( maybe only existing for 1% of all objects ) and the entire thing would be manageable, and changes such as modifications or new or deleted permissions could be identified easily. The event log could perhaps be used to show the history of such creations/deletions/changes as well. It's just such a mess now.

 

Bonus philosophical question of the day: was SETACL a godsend or a thorn in our side. ( NB: it came along in the WinXP transition era, but in the years since most of the same functionality has been added to setup applications like INNO etc. When you create a setup.exe these days it's as simple as a checkbox or added parameter to specify permissions on not only the distribution files, but anything on the target system. In fact it's really a simple matter to whip up a "permissions fixer" standalone EXE that corrects/creates problems on a system. )

 

 


... Let him who hath understanding reckon the Number Of The Beast ...


#17
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,401 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Yep :), but I doubt that "plain" filesystem journaling represents an effective "safety measure" (when such a number of programs and services run in the background).

 

Having a transactional filesystem may possibly help (due to the "atomic" nature of the transaction log) and not-so-casually transactional NTFS was introduced with Vista :ph34r:

 

But (just for the record), at application level, the thingy was rather poorly implemented, or documented, or both :w00t:, to the point that it is now "deprecated" :

http://msdn.microsof...0(v=vs.85).aspx

TxF was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources – such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.

 

The good MS guys, however seemingly "invented" a transactional exFAT for Windows Ce/Phone, TexFAT (of which exist seemingly also a 2.x version, completely UNdocumented) see:

http://www.forensicf...wtopic/t=11393/

http://www.forensicf...571453/#6571453

 

That filesystem may be (if ever it will be available/usable on "real" Windows PC's) a good "no permission/no unneeded fluff" kind of solution.

 

But of course this - even if it will ever happen - won't change in any way the situation of the Registry which is in itself a filesystem (and actually very similar to NTFS) if you look at it from the right angle ;):

http://reboot.pro/to...s-a-filesystem/

 

A nice experiment (if anyone has time/will) would be to try making a Windows 7 "standard" install (the one with the 100 Mb stupid "boot" partition - which the good MS guys call "system" - and a second "system" partition - the one which the good MS guys call "boot").

Then replace the second partition with a "copy of it" but formatted with a UDF (or exFAT or TexFAT) filesystem.

Will it work? (i.e. has the BOOTMGR the capability to access UDF (or exFAT or TexFAT) filesystems?)  :unsure:

 

jaclaz 

 

P.S:: IN the mentioned thread on reboot.pro:

http://reboot.pro/to...rdlinked-files/

another member posted his experience with manifest files that can be removed from the WinSXS directory safely, so even 7 is possible.

If you want to do do the test, remember that the 7 installation footprint on disk will grow to 9 Gb or more, almost 10 Gb if I recall correctly.


Edited by jaclaz, 04 April 2014 - 04:25 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN