I need the heap to be verified each time the garbage collector (GC) finishes its work. I read this can be done by setting the environment variable COMPLUS_HeapVerify to 1. But how exactly do I set this variable?
I read this can be done via Computer/Advanced System Settings/Advanced/Environment Variables (Windows 7), somebody tells I should set up a new system variable (here), others tell this should be a user variable (here).
Is this approach correct and which (system or user) variable should be set?
The approach you mentioned is absolutely correct.
Go to Control Panel->System Properties->Advanced System Settings->Environment Variables.
If you have administrator privileges, add a system variable called “COMPLUS_HeapVerify” with a value of “1”; otherwise — add the user one. Note, in the second case you might need to log out and log on.
Hope that helps.
Related
Is it possible to execute a method as a different user in Linux (or SELinux specifically)? The programs that I have run in individual sandboxes, each with a different user and process id. I have a situation where I have to execute a branch of code as a different user and with different process id to prevent the access of the memory and disk space of the code that's spawning it.
If not possible, can you throw some light on how much of the kernel code has to be changed to achieve it? (I understand its subjective. Alternatively, if you can suggest what and how to go about it, that will be much helpful).
Protecting some resources from other codes executing on the same machine is precisely what lead to the process and UID invention.
If you are searching for a mechanism that looks like a simple function call, I would say it's impossible because it requires the memory to be shared between the caller and the callee. However, using fork/exec (or wrappers like system()) will give you some isolation as long as you deal with parameters/results using system objects like program parameters or pipes.
Although, the fact that *nix user is meant to protect processes from one-another, requires that an explicit relationship be built between two users to have one user act on behalf of the other.
Actually, you may want to:
define a sudoers policy which gives the right to your first user to run a command (or a particular command) as the second one.
use popen() (or system()) in your first program to call the less privileged code.
if any, pass the parameters and parse the result from stdout
As an extra, you may use the same binary for both executions, this way, all the code can be at the same location.
i am using the sshd_config variable PermitUserEnvironment
#/etc/ssh/sshd_config
PermitUserEnvironment yes
to set something like "REALUSERNAME" on every key in the /root/.ssh/authorized_keys file.
#/root/.ssh/authorized_keys
environment="REALUSER=custom_value" ssh-rsa AAAAB3....
But i have trouble accessing the value in the script triggered by pam_exec in /etc/pam.d/sshd
my best guess is that the pam script is executed before the environment variables are set? So what are my options?
i tried pam_env
#/etc/security/pam_env.conf
PAM_REALUSER DEFAULT="unkonwn" OVERRIDE=${REALUSER}
this is the custom part of my pam.d/ssh file
#/etc/pam.d/sshd
session required pam_env.so readenv=1
session optional pam_exec.so seteuid /usr/local/bin/scripts/my_script
even vars like SSH_CONNECTION seem not to be available which feels odd to me. The information must surely be avaible at the time of script executing but the variable is not set or i am doing it wrong.
i used to (successfully) trigger the script within /etc/profile so i am very confident that the issue is not within my custom script
But I have trouble accessing the value in the script triggered by pam_exec in /etc/pam.d/sshd
my best guess is that the pam script is executed before the environment variables are set? So what are my options?
Yes, you are right. The environment variables from authorized keys are set up in do_setup_env() function, which is called after pam_session.
If you want to access these variables, I recommend you to set up ForceCommand or special shell for the user, which will be wrapper around normal shell, after you evaluate your variables.
But note that setting this for root, which is unlimited will allow your users to do whatever they want (even changing the keys, your environment variables), regardless your setup.
I cannot access my system environment variables from my administrative user account. I am still able to access my user environment variables though. When I try to access SystemPropertiesAdvanced.exe from the Control Panel > All Control Panel Items > System > Advanced system settings, I get an error: "Windows cannot find %windir%\system32\systempropertiesadvance.exe"
From a cmd window, I entered "echo %windir%" and it wasn't set. After that I entered "set" and saw only user environment variables. I navigated to: C:\Windows\System32 and ran SystemPropertiesAdvanced.exe. This worked and I saw my complete list of system variables, but I'm wondering if there is a setting I can adjust which will allow my user account access to the system variables.
Go to C:\Windows\System32\ and find SystemPropertiesAdvanced.exe.
Start the program and click on Environment Variables button.
Then add new (Name: windir, Value: %SystemRoot%) to system variables.
I think I did have access, but the problem was that my user and system %PATH% variables were different. I'm not sure, but I think the user variables are used before system variables. I compared the values of user vs system and my user variable was much smaller. With this I concluded that it mush have been trying to access the wrong variable. Now I don't get the error messages anymore.
I have a do file from which I would like to select a few lines of code and then run them using the Execute (do) button. The problem is that there are a bunch of local macros defined in this do file. I can run them, but then in the Stata command prompt the local macros are not accessible. Thus, I think I should just be using global macros.
I have looked in several places and haven't been able to find out what scope macro variables actually have. I realize that local macros are only defined in the instance (for example, a do file) they are originally created in.
But for global macros, are they stored forever and every time I open up a new instance of Stata I will still have the global macros from previous sessions?
Or do they get deleted each time I exit out of Stata (or something else)?
Global means visible everywhere, but not for all time.
Global macros you create disappear at the end of a session.
When you start a session, or indeed at any time, macro list shows global and also local macros visible within your current locale. Here "locale" is not a word used in Stata documentation, but a nonce coinage to denote the current interactive session, the current program, the current contents of the do-file editor or a selection thereof, namely the code currently running. The difference is that local macros are only visible within the locale in which they are defined; global macros are visible in any locale.
Some global macros appear to be created on the fly; thus if I wish for a display of current date or time I can
di "$S_DATE"
di "$S_TIME"
and Stata will access the operating system for such details.
But the easiest way to answer your question is to experiment. Define some global such as
global whoami "bill999"
di "$whoami"
and then sign off and start a new session and see whether it is saved by Stata. Alternatively, save the current dataset and use the same dataset in a new session and see whether globals survive the journey.
See also help notes.
I have written a kernel module that creates a /proc file and reads values written into it from a user program,say user.c
Now I want restrict permissions for this /proc file.I have restricted permissions based on userid using the 'current' kernel variable by checking current->euid.
My question: Is there a way to restrict this based on the program too? i.e. only user.c should be able to write to this proc file and not any other program.I could not find any parameters in task_struct that would help me do this. Can you please suggest a way to do this?
In your proc writer implementation (that is, inside the kernel module) the best you can do is check the value of current (a struct task *), which holds (among other things) valuable fields such as comm (16-character argv[0]), pid, uid, etc (Basically, everything you see in /proc//status. You can also check the original exe name (like you see in /proc//exe), to see if it's a well known path. You can then return an error.
Caveat: Anyone could rename their opening process to be one of your "allowed" programs, if you go by "comm", and there are ways to defeat the "exe" protection. This will only make it slightly harder, but not impossible for someone to get around. A more comprehensive and stronger solution would require you to peek at the user mode memory of the program, which is possible, but too complicated for a brief answer.
Note: Permission parameters won't work, don't even bother. They go by classic UNIX ACL, which is u/g/o - so you can't filter by PID.