How does AIM ignore NTFS Deny permission?

Maybe i’m the only one, but i have a share on a hard drive for people to access some of my videos of me and friends. I was experimenting with rights and permissions and denied full access to the Everyone group. But, my test subjects (other aim users) are still able to get into the share and do file transfers as if there was no Deny permission set. Can anyone shed some light?

p.s. - The share is on a completely different screen name than the one in my profile.

Because NTFS allows or denies access based on who owns the process that’s accessing the file. Windows doesn’t know anything about AIM users or what rights they should have, since it’s all coming in over the AIM application that you launched. “Everyone” in this case is for people logging into the machine directly or using Windows networking. It doesn’t apply to AIM, or most other applications (Webservers, P2P apps, etc) for that matter.

Now, if someone else were to log into the computer and run their own instance of AIM (or anything else) or try to access the files from a network share, they wouldn’t be able to access the file.

I’m not sure if there’s a way to specifically limit who has access to what via AIM. Someone with more experience with the windows client might be able to help you with that.

I’m not familiar with the AIM client in detail, but you can probably do what you want by:

  1. Create a new user on your PC

  2. Set the permissions on your various drives & folders so that new user only has access to what you want to share with AIM.

  3. Use Run as … to start your AIM client using the restricted user from step 1. To use Run as, hold the shift button down & right click on the entry in the start manu or desktop icon. You’ll see a run as… entry in the pop-up menu. Choose that.

The first time you do that the IM client may well act like it’s not configured, like a first time installation. That’s not surprising since it is the first time that user has used it. Fill out the needed connection info and you’ll (probably) be in business.

Exactly.

The fact that Windows services run as the LocalSystem account, by default, is one of the reasons behind the serious security issues that Windows suffers from.

So basically you’re saying that Everybody does not include LocalSystem?

But surely AIM would run under the current user who surely would belong in Everybody? (Not that I have never used AIM so I guess it might contain something unusual, as allowing access to file shares is pretty unusual in itself already :p)

[QUOTE=SlickRoenick]
Maybe i’m the only one, but i have a share on a hard drive for people to access some of my videos of me and friends. I was experimenting with rights and permissions and denied full access to the Everyone group. But, my test subjects (other aim users) are still able to get into the share and do file transfers as if there was no Deny permission set. Can anyone shed some light?

Did you remove the Everyone group or give the Everyone group the ‘No Access’ permission?

Did you set the permission at the file level or the share level or both?

Certain permission changes at the share level will only take effect after logging out and back in.

I’m not worried about any of my buddies getting the files. Those files are there for them to download whenever they want. I was just curious how AIM got around the permissions.

But AIM doesn’t run as a service on my comptuer, it just runs as the application.

I added Everyone and checked the Full Access box under Deny. I set the folder to Deny Full Access. It isn’t a Windows share, just an AIM share.
As an afterthought, could AIM perhaps be making a cache of those files and that is how it is able to read them thru “Get File” and why i get denied thru Explorer? And going back to my OP, they *cannot * *download * the denied files, but they *can read * them.

As it does on mine. However, it does use the RPC service and that lends the vulnerability. If the RPC service itself is weakk or if the AIM call to it is sufficiently bad: voila, insecurityl

From the Process Explorer table of the AIM process:

Port \RPC Control\OLECE467E78EE5B417FA5AEC41A606E

I believe if you are member of the Administrator group, you cannot deny yourself access to anything. AIM runs as you, so it can read everything.