Set Access Control Behavior Change in X11

[Aaron Young]

I recently upgraded from Install Aware Studio X9 to X11 and have noticed a behavior change involving the Set Access Control command.

When checking the User Accounts/Groups to include, only the bottom-most checked item will actually be applied.
For example, checking "Everyone", "Current User" and "Authenticated Users" will only set permissions for "Authenticated Users", checking "Everyone" and "Current User" will only set permissions for "Current User", etc..

This is a change in behavior from X9 where all checked users would have their permissions set.

In addition, when checking "Read" and "Write" permission types in X9 this would result in Full Control access, in X11 this results in Special access which includes only Read and Write.

I can work around this, but I didn't see any documentation of this behavior change, so thought I should report it as a bug.
It also means I now have to update projects that I otherwise didn't need to modify.

- Aaron.

[Aaron Young]

After implementing what I thought was a workaround to this change in behavior (granting "everyone" full access), I
have run into another, much more concerning, change in behavior...

It seems that installed files are no longer inheriting permissions from the parent folder created by the install.
In InstallAware X9 installed files would inherit their permissions, in InstallAware X11 they are inheriting from the parent of the folder (a non-installed folder.)

This is a big problem for out installations and if there's no way to correct this, I will have to rollback to InstallAware X9.

For clarity, the install is creating a sub-folder using the "Call DLL Function" and the "CreateDirectoryA" function prior to calling "Apply Install"

"Set Access Control" is called immediately after the creation of the folder to assign the permissions to this new folder into which files will be installed.

Does the order in which these things occur prior to calling "Apply Install" now make a difference?
Because the "Install File" calls are occurring before the "Call DLL Function" to create the directory which is pretty much the last thing I do before calling "Apply Install".

- Aaron.

[Aaron Young]

At this point I am stuck and require some advice on how to proceed.

I have tried making sure I set permissions on the folder prior to installing any files.
I have tried using the "Create Folder" command (calling Apply Install afterward) then setting permissions.
No matter what I do, the files installed to this folder do NOT inherit the folder permissions, it appears that the permissions are being assigned so they apply to "This folder and subfolders", meaning files are excluded.

Is this something other users of X11 are experiencing?

Looking back through the post history I can find a lot of instances where users have run into problems using the "Set Access Control" command (indeed I found this post; https://www.installaware.com/forums/viewtopic.php?t=3820 I myself made many years ago with a very similar problem) and it never seems to be addressed - why is that?

Now I have to decide whether I am going to rollback to X9 and hope this bug is fixed in a future update, or whether I'm
going to code my own support file to set permissions for me outside of IA.

In either case, I find myself having to reevaluate whether IA is a viable option for my company to continue using after more than a decade.

Regards,

- Aaron.

[FrancescoT]

You should provide us with a minimum setup project that replicates the issue(s) as you described here.

This minimum project must no have any dependencies on your development eco-system (such as files to be installed, databases to connect to, and so forth). This minimum project must do nothing other than consistently reproduce the suspected issue.

Once you ready, please contact me at; support@installaware.com.

Thanks!

[FrancescoT]

This to inform that for what concerns the problem reported here, it will be publicly available a fix very soon as part of our next product update.

We recently worked very hard around our security engine. Its core has been redesigned in order to address various other problems, and not less important, to give our users more efficient results when using the "Set Access Control" command.

Our main intent was to release a drastic improvement of the security commands over the previous versions, and not to introduce a possible regression of course.

Please accept our apologies for any inconvenience caused.