Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is www.addsuminc.com. Call us at 800-648-6258 or 801-277-9240. We also maintain www.advancedaccounting.us so that older Business Tools users in particular have a greater chance to find us.

Follow

We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address: noreply@blogger.com.

Follow by e-mail

Tuesday, September 27, 2016

When the requested security information is unavailable . . .


A rather peculiar situation relating to Windows security settings can occur if a copy of a file is subsequently placed into a previously shared folder that is not owned by any object (group) and/or that file is placed into the shared folder by a user that is not a member of group that has security privileges to the folder.

The highly unexpected result of this situation is that while the user is allowed to place a file (which is the same thing as "writing" to the folder) into the shared location (and it doesn't matter whether it is a new file, or a file that is replacing the same file that is already correctly shared!)  and can run/execute or read the file, other Windows users will be denied the ability to do the same.   

In the case of our software, the user will receive a message indicating that basically the program cannot be run or loaded.   Inspecting the properties of the file on the server and viewing the security tab, the rather unhelpful "The requested security information is either unavailable or can't be displayed" message is displayed:





This seems to be a  poorly designed aspect of Windows security.  This means that as a software developer, we cannot be sure that a file that we install on a remote system can be properly run by other users in a multi-user environment because of some pre-existing user/folders rights issue even though we in fact are able to write to that folder and even though it otherwise gives the appearance of working exactly as it should.  This is really not something our programs have control over and hypothetically should be none of our concern.   We should not have to double check the rights of each and every file  located on a server that we may not even have direct access to in every situation.

When we first ran into this problem simply when placing three new files into a program folder (and which we could test and run without issues but the end user ultimately could not) from a Terminal Services server (a common situation), we resolved the issue by getting access to the server, right clicking on each file and by "taking ownership" of them:




We then proceeded to add the "Everyone" group to file making sure users in the group had read/write rights.

But then more recently and on the same system (running Windows 2011 SBS Server), we replaced an existing program file via the Terminal Services server, we were again able to run and test it from that server and all seemed to be well,  but then today we were contacted by the end user who in fact could not run the recently replaced program.  Yet the file that was replaced had the exact same file name and was placed in the exact same folder that all users who had rights to that option within our software were able to previously utilize and now were being denied access.

Examining the folder's security, we noticed that there were no owners/groups assigned at the folder level.  Perhaps all of the files were all initially directly selected and shared in the folder previously (although this would not explain why a replacement file still failed nor why we could copy new files or replace existing ones in that folder at will).   By adding the  "Everyone" and "Administrator" objects/groups to the security of the folder itself, this will hopefully resolve future issues on this system of updating their installed software (and some testing conducted today placing new and replacement files into this folder and then logging into the server to view the security properties of those files indicates that it does).






No comments:

Post a Comment