I have an issue related to reading from the registry of Windows. I need to retrieve information about USB devices connected and removed before. The most important info for me is date/time of connecting and removing.
One of the paths I can get is this:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&xxx&xxx&xxx\xxxxxxxxxxxxx\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0065
In default mode I don't have an access to the branch Properties even when I try to open the key of registry via aGUI. I can change the settings of this particular key Properties to get an access, but another similar key Properties in another branches will still be closed. So the question is, why there is no access to them?
But when the key is opened there is no information about USB I can read using script based on the winreg Python library.
This data looks this way:
I found a module for processing the registry keys, https://github.com/woanware/usbdeviceforensics. Using this module, I have to pass the path to the hives of the registry and then to invoke the method process(path). I pass this path C:\Windows\System32\config where such hives like SYSTEM, SOFTWARE and others are located. But the module just skips reading some files because an error "Permission denied" appears. BTW I run the script with an administrator rights.
Why there is "Permission denied"? I can't use this useful module just because of this error.
Related
What exactly is --user-data-dir specifiying?
From --help parameter:
--user-data-dir <dir> Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code.
Is it storing some temporary files there?
Is it about the access path to config files?
I am asking as I want to run VSCode (or Codium to be more exact) with sudo (I want to edit system config file that is read restricted) which requires this parameter for reasons unclear to me.
Since sudo-ing VS Code at command-line launch is only a thing on Linux, this question assumes you're on Linux, and restricts its context to Linux.
TL;DR
To answer your question directly: the user-data-dir parameter points to a folder where all personalisation except extensions resides — unique to each user.
Why does sudo-ing Code need --user-data-dir?
In typical installations of either OS and VS Code, this folder owned by the regular user cannot be accessed by the superuser.
Hence a VS Code session running with effective UID=0 tries but fails to write to the invoking user's (not the superuser's) config folder. This is what the error message prevents from happening, by forcing the user to provide an explicit root-accessible folder.
Detailed Explanation
There are two main folders that VS Code uses to store configuration data:
An extensions folder (self explanatory) — contained in ~/.vscode[1]
user-data-dir; a folder for all other personalisable things (settings, keybindings, GitHub/MS account credential caches, themes, tasks.json, you name it)[2]
On Linux the latter is located in ~/.config/Code, and has file permissions mode 0700 (unreadable and unwritable by anybody other than the owner).
This causes issues, as VS Code tries and fails to access said directory. The logical solution is to either modify the permissions (recursively) of ~/.config/Code to allow root access, or — arguably saner and objectively more privacy-respecting — to use a separate directory altogether for the sudo'ed VS Code to access.
The latter strategy is what the community decided to adopt at large; this commit from 2016 started making it compulsory to pass an explicit --user-data-dir when sudo-ing VS Code on Linux.
Should You be Doing This in the First Place?
Probably not! If your goal is to modify system config files, then you could stick to an un-elevated instance of Code, which would prompt you to Save as Admin... when you try to save. See this answer on Ask Ubuntu on why you probably want to avoid elevating VS Code without reason (unless you understand the risks and/or have to), and this one on the same thread on what you could do instead.
However, if the concerned file is read-restricted to root as well, as in the O.P’s case, then you hardly have a choice 😕; sudo away! 😀
[1] & [2]: If you want to know more about the above two folder paths on different OSes, see [1] and [2]
Hope this was helpful!
It might be helpful to easily find the default location of the user-data-dir on any OS. It can be found with this command:
Developer: Open User Data Folder
workbench.action.openUserDataFolder
which is in the Insiders Build v1.75 now, Stable soon. Opens your OS file explorer app to the location.
I have an Informatica workflow that is supposed to generate a .dat file.
The issues is that the wroflow creates a 0 byte file, but then can not write to the file it JUST created. It's baffling.
The target directory is a linux server, and there is a developer on our team that is able to run the workflow just fine, without this file-writing issue.
However, I have checked with our linux admins and several of them have confiremd that there is no major difference in access/permissions between her linux ID and my own. She is in two more user groups than I am, but I have been told that they would not have anything to do with this issue.
The ID used by the connection object is also in the same user group as my id on the linux server, enduser. Therefore it should be able to write to my home directory.
The workaround we have devised is to remove the files using my id, touch the files and then chmod them. This allows the id used by the Informatica connection object to write to the files, but it is not a permanent (or correct) fix.
My best guess is that this is most likely some sort of (very obscure) Linux environment issue.
I am also not able to make any changes to the Informatica workflow or mapping, since it is built correctly and this issue appears to be completely local to certain linux user ID's.
Does the etluser have write permissions? have you tried running a post session command script for chmod and giving full permissions and then writing into the file?
I am receiving the below error when I'm trying to build the solution file from MSBUILD.
I'm building the solution file from ClearCase integration stream .
When I do the same from a different system it works fine on the integration stream.
I have tried creating and writing the file into the N/W drive & it works fine.
But when I build it through CruiseControl it is throwing the following error.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3041,9):
error MSB3491:
Could not write lines to file "obj\DAL.csproj.FileListAbsolute.txt".
Access to the path 'M:\yj73_SRDV3G_Proj_01_00_int\SRM_COMP\SRDV3G_Project\CRDB_V3\Application_Source\DAL\obj\DAL.csproj.FileListAbsolute.txt' is denied.
Two usual causes:
The CLEARCASE_PRIMARY_GROUP environment variable is incorrectly set and don't reference the primary or secondary group of the Vob \SRM_COMP (see cleartool descr -l vob:\SRM_COMP for a list of those groups)
The path is somehow not selected by the current config spec.
It is best to do a cleartool ls in M:\yj73_SRDV3G_Proj_01_00_int\SRM_COMP\SRDV3G_Project\CRDB_V3\Application_Source\DAL to see how ClearCase displays obj.
The OP user1383839 confirms not using the right account for the Build Loop, which means it didn't benefit from the right environment variable, hence the "access denied" message.
Or you can also "runas" the project as a different user (see "Running cruise control.net under different credentials")
This issue got Fixed !:)
I was using the local account Previous
you need to go to the properties of the cruise control and change the account it is being used.
To start with I'll say I've read the post here and I'm still having trouble.
I'm trying to create a CE6 image with a hive-based registry that actually stores results through a reboot.
I've ticked the hive settings in the catalog items.
In common.reg, I've set the location of the hive ([HKEY_LOCAL_MACHINE\init\BootVars] "SystemHive") to "Hard Drive\Registry" (Note: the flash shows up as a device called "Hard Drive")
In common.reg, I've set "Flags"=dword:3 in the same place to get the device manager loaded along with the storage manager
I've verified that these settings are wrapped in "; HIVE BOOT SECTION"
This is where it starts to fall over. It all compiles fine, but on the target system, when it boots, I get:
A directory, called "Hard Disk" where a registry is put
A device, name called "Hard Disk2" where the permanent flash is
Any changes made to the registry are lost on a reboot
What am I still missing?
Why is the registry not being stored on the flash?
Strangly, if I create a random file/directory in the registry directory, it is still there after a reboot, so even though this directory isn't on the other partition (where I tried to put it), it does appear to be permanent. If it is permanent, why don't registry settings save (ie Ethernet adapter IP addresses?)
I'm not using any specific profiles, so I'm at a loss as to what the last step is to make this hive registry a permanent store.
First, I hope you are not changing common.reg directly. You should never change public code. If you want to change public registry keys you need set them in your project.reg or platform.reg and they will override the public settings.
SystemHive should be set to the name of the directory to which you want to store the hive files without the name of the device.
In your case:
"SystemHive"="Registry\\system.hv"
Quote from the MSDN source:
Do not include the name of the file system on which the file is stored. The system will determine which file system to use based on other registry settings.
Update regarding your second comment (source):
If this value is present under HKEY_LOCAL_MACHINE, it indicates that the system hive has been restored successfully. If it is present under HKEY_CURRENT_USER, it indicates that the user hive was successfully restored.
Are you flushing the changes you make?
Check that you don't have a wierd implementation of IOCTL_HAL_GET_HIVE_CLEAN_FLAG (source) - your system might be returning a true value to clean the system registry every boot.
You can add a thread that will periodically flush your registry (though I'd recommend excluding it and let each application flush its own changes) - PRJ_ENABLE_REGFLUSH_THREAD
Since 2005, when Microsoft prevented HtmlHelp functioning off a network share, e.g.:
\\appserver\tos\PointScanner.exe
\\appserver\tos\PointScanner.chm
What are we supposed to do instead?
(Given that the application is not installed locally.)
To rephrase: What is Microsoft's intended, supported, out-of-the-box, help solution?
You can allow access via the Registry setting described here:
http://support.microsoft.com/kb/896054/
If you don't want to open any security vulnerabilities by modifying Registry settings your application could also create a local copy of the .chm file, e.g. in the users temp folder (%TMP%) and open the help from there. You can remove the file again when your application exits (in case you don't want to leave anything behind on the user's workstation)
I started with the registry change mentioned by divo. Eventually I moved from network folder based chm files to actual "html help". This was easy for me since I use RoboHelp which can generate either format from the same source code.