On 5/9/2014 10:59 AM, Pedro de Oliveira wrote: > Hi Jeffrey thanks for replying. > > On Fri, May 9, 2014 at 3:40 PM, Jeffrey Altman > <jalt...@your-file-system.com <mailto:jalt...@your-file-system.com>> wrote: > > On 5/9/2014 6:22 AM, Pedro de Oliveira wrote: > > Hi, > > > > I want to announce a little app that I made at work that allows to > apply > > OpenAFS ACLs recursively on Windows. Because the current way to apply > > acls on Windows is a bit difficult for normal users. > > I am concerned that this application can cause serious harm as currently > implemented. > > https://github.com/falsovsky/ACLAFS/blob/master/screenshot.png > > It does not show the end user the current list of permissions for all > groups and users included in the ACL. It does not provide a mechanism > to "clean" the ACL nor does it handle negative ACLs. All of which are > provided in the AFS Explorer Shell Extension provided with the OpenAFS > distribution. Select the object to be modified in the Explorer Shell, > right-click to display the context menu and select Properties. The "AFS > ACL" tab provides the user to ability to adjust the ACLs. > > > It only shows the permissions for the user/group typed in the "identifier".
Only showing the permission for one user or group at a time is a
problem. It doesn't convey to the end user what the actual scope of the
permissions are.
> It allows to "clean" the ACL, just uncheck which ones you want to
> remove, or unselect all and it will use setacl none.
"setacl none" is not the same as "setacl -clean". Cleaning the ACL
means emptying it of all positive and negative permissions for all users
and groups.
> In addition, the recursive behavior crosses volume boundaries because it
> is unaware of mount points and symlinks. The side effect of this tool
> is that it will add/modify the specified user/group to the ACL of every
> object that can be reached as a subdirectory. It will not follow the
> behavior of Windows that when applying recursive security permissions
> that the permissions on the children object must match those set on the
> parent.
>
>
> Yes, that can happen, but in our case the users wont do any of those
> customizations (more mount points, symlinks etc), only a mapped to the
> AFS "share", so thats no a problem for us ATM.
Any user can create a mount point or a symlink to any other volume.
Counting on end user ignorance is unwise.
> We just needed a quick and easy way to apply ACLs recursively and I did
> this as a quick tool to help out users and my fellow sysadmins. I know
> its not perfect, but its usefull enough to do the stuff we need. So
> thats why I shared it, because it can help out more people.
Giving your own users a tool that can cause unwanted side effects is one
thing. Giving the rest of the world a tool that can cause unwanted
side effects is something else. Please do not share a tool that can
cause unintended data exposures when used in environments that are not
exactly the same as your organization's.
> Many organizations today have experienced unintentional data exposures
> or breaches due to incorrectly set ACLs in AFS. I believe this tool as
> currently implemented will make such exposures more likely.
>
> Instead of deploying a new graphical tool to set ACLs I would prefer
> that you modify the Explorer Shell extension to support cloning the
> permission list defined by the user to child objects within the same
> volume. That will be consistent with existing Windows behavior and will
> be consistent with end user expectations that ACLs be set via the object
> Properties.
>
>
> I would like to help out with that, but I dont believe I have enough
> knowledge about OpenAFS and Windows internals to make those changes. I
> can try it out if anyone is willing to mentor me.
The Explorer Shell extension is a C++ DLL that is written using the
Win32 API. The source code resides in src\WINNT\client_exp\. It
already has the UI and code for reading and setting the ACLs.
The recursive logic should do the following:
1. remember the original ACL on root object being modified.
2. enumerate all child directories filtering out those directories that
have the reparse point attribute. These will be mount points or symlinks.
3. compare the original ACL on the root object to the current ACL on the
child object.
3a. If the two ACLs match, apply the new ACL to the child object
3b. If the two ACLs do not match, ask the user if the new ACL should
be applied to the child. Only if the user says 'yes', should
the ACL be applied. The prompting dialog may have a "yes to all"
option which indicates that the ACL should be applied to all
future child objects even if the original ACL does not match.
4. If the SetACL fails, the user should be notified and given the
option of halting the operation or ignoring all future failures.
This can happen when the user does not have administrative
privileges.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
