Win7 shares possible huge security hole

Potentialy due to all problems with connecting XP to win7 people
are already glad to be able to connect to WIN7, but there seems to be
a huge scurity hole in the process:

   Note

As I examin shares on win7 (controll panel shares)
ACL's require a full grant on Everyone// it's unclear what read and change and full mean...
As previous inter connections connections are made effects are less clear restriction seem to be less strickt
what makes the shares ACL tricky to handle and test for security problems!!!!!

The ACL Everyone: FULL seems to be required for all shares to work ???!!!!

   Note

but everyone is rather LARGE:


"The Everyone group encompasses":
well everyone. That is, it includes all the built it users and groups that
come with Windows XP/win7 as well as any administrator defined users and groups.
It also includes the service and system accounts that are created and any anonymous
accounts that connect to the computer without providing any login credentials.
Lastly, it includes the Guest account.

As an acl GROUP grant is placed on the share ( a group of users(NOT individual users,but this is unmanagable)) the statement seems to be ignored !!

   Note

The requirement of an EVERYONE:FULL is IMPLICITELY A SECURITY BREACH....
Relying on the file security restriction is a different matter.
The SHARED security is the first security protection setting it: The need to use EVERYONE:FULL is killing the security purpose

User/password all username passwords are synced by batch process and used on ALL machines
files access to the files is granted by group but for the sake of the exercise a grant to authenticated users is added
to ensure the file's protection is not the problem (implicit security breach but this is a test)

what is a problem is the need to reboot.... since(clear credentials) all gets confused by first opening another share by that user
then the state of the share switches virtually to authenticated user instead of everyone (first refused/then allowed(once logged in guest plays less in the game) UGLY to reproduce

Basical settings and tests:

share files: authenticated user : full except special permissions (just for tests to avoid file protection issues)
group full permissions
system full permissions (came from inheritance)
admin(local) full permissions (test side effect but can not harm,user has admin privileged as well)
users r/e/list (came from inheritance)
no deny

Test user is member of group group defined on both sides (all machines)
behavior identical on all machines

Share permissions basic setting (common for all tests):
group full permission
no deny



Share permission tests:
everyone: full all works
everyone : change can write
everyone : read no write access
everyone : none (gets deleted ) windows can not access
annonymous login read no access
change no access
full no access

Conclusion: everyone:full is essential but is heavy security breach really everyone can get at badly protected files
(file system protection!!!!!!!!=assumed out of control due to possible future errors anyhow is not reliable this way !!!)
an explict User Name: Read/full can write/can read But this is completely un-maintainable what does NOT help the security!


PS: takes a long time (multiple seconds to translate SID in group name
during this time no permissions shown (controll pannel server)
CPU i7 12 Gig 10 terrabyte win7 sp1 ultimate (both machines) fresh generated
gigabit ethernet link



the issue has nothing to do with passwords or patches.... BUT WITH The assumed way of working

as it was working in XP and is NOT WORKING in windows 7.(has NEVER WORKED SP0/SP1!)

Due to this fact the manufacturing (intentionally? since test seem to be done badly on basic functions)
supports hackers and blocks users to really secure their system.

Basic Understanding of Share and NTFS Permissions
To understand Sharing and NTFS permissions (Security Tab), when connecting to a Shared Resource (folder, printer, etc), the NTFS permissions are combined with the Share permissions to provide the Most Restrictive.

This means that if a user has Full Control on the Share permissions, and only Read on the NTFS permissions (Security Tab), the Effective (resulting) permissions is the user will only have Read. That's why we can set higher Share permissions at the parent for the initial access, then control the resulting or Effective permissions with NTFS. No passwords are needed other than the user being successfully logged on to the domain. When a user is logged on successfully to a domain/workgroup, an access token is given the user account. The access token is compared to the ACL (Access Control List) in the Share and NTFS (security tab) permissions to determine access. That's why no passwords are required, and is much easier than trying to deal with multiple passwords. The system simply uses the AD/workgroup user account for access enumeration.

Therefore due to the Most Restrictive evaluation, the easiest way to set permissions is to provide the Users (preferrably by Groups), Full Control on the Share side, but lock it down on the NTFS side (Security Tab). It SHOULD works nicely, all the time, and is easier to document and keep track.

MY claim is the above DOES NOT WORK IN WIN7!!!!!!!
Yes it works for users !!!!! BUT THAT IS NOT PREFERABLE AND UN-MAINTAINABILITY!!!!

IT SEEMS NOT TO WORK FOR GROUP's (Correctly defined in control panel and working correctly for file access permissions[non share])
THIS BUG ????!!!! FORCES HUGE SECURITY RISKS on a OS that is supposed/mentioned state of the art.

(Sorry for shouting, is intended but not intended to anyone personally)
My cry is a CRY for help, is the above really as I state, or am I missing Something
that is the reason I pledge the world for help

Any help link or info is welcome
Where can I find more on this, links to more professional security setup please.-