I posted this question a while ago regarding where to store non-user specific application data on Linux.
As you can see, I intended to use "/Library/Application Support” on Mac and perhaps "/var/lib" or "/usr/share" on Linux.
On an existing application (currently Windows only) we use “\ProgramData” on Vista & Windows 7 and “\Documents and Settings\All Users“ on Windows XP (both obtained using System.getenv("ALLUSERSPROFILE"), which does not work on Mac or Linux).
The problem I am finding with the Mac & Linux locations (unlike the Windows ones) is that they are not accessible by non-root/admin users, which sort of defeats the purpose of using them.
What is the best practice is this case? We could simply store the application data in the user's home directory. I wouldn't actually be dead against this, as it seems reasonable for the application to appear completely 'new' when a new user tries using it. The main problem this gives us is that each user would have to enter the serial number in order to activate the application (the activation info is part of the 'application data' we need to store). This isn't really ideal.
That said, if there is no real alternative then I suppose it will have to do.
What do you mean by non-user specific application data?
Read-only resources needed by application, such as localization strings or button icons:
on Mac they are stored in application bundle itself, in Resources subfolder
on Linux, they can be stored near application binary, in /opt/<app>/etc for instance.
Read/write properties, such as serial number:
you can consider this information as user-specific application data, so it should go somewhere in $HOME directory
you can consider this information as computer-wide application data, in which case its setting should be perfomed during software installation process, i.e., with administrative privileges.
/Users/Shared/ is writable for everyone. That said, if you need to support computer-wide licenses, the best place for serial numbers, IMHO, is indeed /Library/Application Support. You would have to use Authorization Services once to ask for an admin password and save the serial number there. If a user fails to enter the admin password, save the serial number in ~/Library/Application Support instead.
Related
We have a VB6 program installed on all of our clients' local C drives, along with an associated VB6 DLL program. The program was written back before my time in the 90s. It was not designed to run off a server or to allow multiple user access to the same EXE at the same time, hence why it's on everyone's C drive. However, all running sessions of it refer to the same database source on a separate SQL Server via ODBC. The database connectivity works fine.
Ok that's all history, with everyone working remotely (Covid19)!
Today however, our clients are all remoting into a virtual server via RD Web. We want them to avoid using our VPN. We have TWO virtual servers allocated to RDweb users: TS01 and TS02, and license for up to 64 users. Every user is automatically allocated one of the two servers. If two people log in at the same time, and one in TS01 and the other in TS02 - everything is fine! It's when a 3rd person logs in and is given either of the servers, and runs the program, is when it crashes, with this error:
The DLL is registered in both Computer\HKEY_CLASSES_ROOT\ and Computer\HKEY_LOCAL_MACHINE\SOFTWARE\, but not LOCAL_USER, which I think is necessary to make this be a multi-user program, within a server environment.
Converting the app is not an option, as we don't have VB6 compilers. Do we need to wrap the DLL in "something"?
Any ideas how to get this legacy program to run for multiple users, are appreciated.
Thanks
Try installing/copying VB program and related DLLs in each users folders (like home folder and shortcuts pointing to these HOME directories). If the program runs, it should update the database in the same way. Sometimes, most workarounds are simple. If they need different locked DLL working space then give them that (May have memory issues later)
Please see this
https://stackoverflow.com/a/345154/12011019
and
https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/april/simplify-app-deployment-with-clickonce-and-registration-free-com
Some DLLs are not designed to be shared and this behaviour cannot be modified without reprogramming. There are in process and out process (threads ) DLLs. Or there can be many other issues. If its not working, its not allowed by design.
https://support.microsoft.com/en-au/help/911359/a-client-application-may-intermittently-receive-an-error-message-when
The shared DLLs that are used system wide do not have this limitation as many they are designed to be used by many applications.
Please try and comment the behaviour.
I am writing a java agent that needs to write a file to a share drive using UNC format (\\servername\directory\subdir\etc).
I am getting "access denied" returned by the agent. The same code will write to the D drive of the same machine using either the D:\ or the UNC format.
I believe that this is a security limitation of Notes and that this can't be done, but hope I am wrong. Does anyone know of a way around this???
Security policy prohibits using FTP, and mapping a drive letter.
I have tried Apache commons FileUtils with no success, as well as just trying to create a File object.
(Note: not tagging java because I need notes specific answers, and tagging XPages even though it is not because the smart people hang out there)
This depends on global or local policies for the windows account which runs the domino server. Normally this is local system. Local System does not have access to mapped drives. Either change the service account which runs domino or give the privileges to the local system account.
I have nodejs running on Centos 7. What bothers me is that any node apps could walk through whole server, changing any files and writing new one. How can I block node app from accessing folders above the level?
This is not specifically a node.js issue, but more a question about how to secure a server from any form of potentially misbehaving program. A massive subject about which whole books have been written.
But to answer your question: any software, including node.js programs, runs in the context of a process that has a user (uid) and group (gid), and standard operating system facilities: file permissions, Access Control Lists (ACLs), etc., determine what a process with a specific uid and gid can access.
If you believe that the node.js program can access the whole server’s file system that suggests that the process is running as the root user, or at least has superuser (su) privileges; which would be considered bad security practice in almost all circumstances.
So run the node.js program as a user with no access outside of an area of the file system to which it has been explicitly granted the minimal possible access.
This CentOS documenation (https://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-context-checking-processanduser.html) might help a little if you are new to the subject.
Where can I create/modify/delete registry keys to share data between users in the Windows 7 registry? Both of the users are non administrators and it shouldn't require admin privileges.
The application I'm working on uses the registry to write a key from userA and then userB can read/modify/delete it. Neither user has admin privileges and it won't be possible to change this.
Is there an official MSDN guide to how to use the registry in Windows 7? Any links describing proper use of the registry would be useful.
You cannot access HKLM without elevation, so you simply cannot do what you described.
I suggest some of the following:
1. Choose other data storage, eg. database, file, etc. that all your users can access.
2. Create a windows service running as LocalSystem (that gives RW access to HKLM) and make your apps talk to the service via named pipes/COM/a socket.
The registry is for writing configuration settings, not for sharing data between users, you're really using it for the wrong purpose.
However, if you have to, the only place in the registry that would make sense even a little would be in the HKEY_LOCAL_MACHINE hive, in Software\yourapp, but I'm fairly sure that there is nowhere in there that's writeable by normal users by default.
If you are able to, you could create that key and then change the permissions for the users group so that they have full access.
This wiki article might help in seeing how the registry is best used.
On Windows 7, access to HKLM is only for apps running as admin. If you have no manifest on the app, it will virtualize, meaning write to a different per-user storage.
I think you should use a config file in a per-application location that is not per-user, like %PROGRAMDATA%, and have your setup/install (which probably does run as admin) write a single key that tells where this file is. The non admin users can then easily read and write the file while using the application.
The registry is not really the right way to do this. Can you give us some more details about what you're actually trying to do?
Are the users logged in at the same time? In this case, some kind of interprocess-communication (IPC) mechanism might work. For example: named pipes, shared memory, sockets, etc.
If not, will you have a process running at all times (i.e. a service)? This could be used as a sort of drop-box mechanism.
If you've got an installer, you could create a directory that's accessible to both users (put them in the same group, for simplicity's sake). Then you could drop message files in there.
In short: the registry is really designed for long-lived configuration settings. Short-lived communications really ought to be done some other way.
I was recently working with a product from Symantech called Norton EndPoint protection. It consists of a server console application and a deployment application and I would like to incorporate their deployment method into a future version of one of my products.
The deployment application allows you to select computer workstations running Win2K, WinXP, or Win7. The selection of workstations is provided from either AD (Active Directory) or NT Domain (WINs/DNS NetBIOS lookup). From the list, one can click and choose which workstations to deploy the end point software which is Symantech's virus & spyware protection suite.
Then, after selecting which workstations should receive the package, the software copies the setup.exe program to each workstation (presumable over the administrative share \pcname\c$) and then commands the workstation to execute setup.exe resulting in the workstation installing the software.
I really like how their product works but not sure what they are doing to accomplish all the steps. I've not done any deep investigations into this such as sniffing the network, etc... and wanted to check here to see if anyone is familiar with what I'm talking about and if you know how it's accomplished or have ideas how it could be accomplished.
My thinking is that they are using the admin share to copy the software to the selected workstations and then issuing an RPC call to command the workstation to do the install.
What's interesting is that the workstations do this without any of the logged in users knowing what's going on until the very end where a reboot is necessary. At which point, the user gets a pop-up asking to reboot now or later, etc... My hunch is that the setup.exe program is popping this message.
To the point: I'm looking to find out the mechanism by which one Windows based machine can tell another to do some action or run some program.
My programming language is C/C++
Any thoughts/suggestions appreciated.
I was also looking into this, since I too want to remote deploy software. I chose to packet sniff pstools since it has proven itself quite reliable in such remote admin tasks.
I must admit I was definitely over-thinking this challenge. You have probably done your packet sniff by now and discovered the same things I have. I hope by leaving this post behind we can assist other developers.
This is how pstools accomplishes execution of arbitrary code:
It copies a system service executable to \\server\admin$ (you either have to already have local admin on the remote machine, or supply credentials). Once the file is copied, it uses the Service Control Manager API to make the copied file a system service and start it.
Obviously, this system service can now do whatever it wants, including binding to an RPC named pipe. In our case, the system service would install an msi. To get confirmation of successful installation you could either remote poll a registry key, or an rpc function. Either way, you should remove the system service when you are done and delete the file (psexec does not do this, I guess they don't want it to be used surreptitiously, and in that case leaving the service behind would at least give an admin a fighting chance of realizing someone had compromised their box.) This method does not require any preconfiguration of the remote machine, simply that you have admin creds and that file sharing and rpc are open in the firewall.
I've seen demos in C# using WMI, but I don't like those solutions. File sharing and RPC are most likely to be open in firewalls. If they aren't, file sharing and remote MMC management of the remote server wouldn't work. WMI can be blocked and still leave these functional.
I've worked with a lot of software that does remote installations, and a lot of them are not as reliable as pstools. My guess is that this is because those developers are using other methods that are not as likely to be open at the firewall level.
The simple solution is often the most elusive. As always, my hat is off to the SysInternals folks. They are true hackers in the positive, old school meaning of the word!
This sort of functionality is also available with products LANDesk and Altiris. You need a daemonized listener on the client side that will listen for instructions/connections from the server. Once a connection is made any number of things can happen: you can transfer files, kick on installation scripts, etc. usually transparently to any users on that box.
I've used the Twisted Framework (http://twistedmatrix.com) to do this with a small handful of Linux machines. It's Python and Linux, not Windows, but the premise is the same: a listening client accepts instructions from a server and executes them. Very simple.
This functionality can also be accomplished with VB/Powershell scripts in a Windows-based domain.