For testing purposes, I often need to go back and forth between the current date and a past date. I wrote a quick powershell script so that I can just double-click a desktop shortcut to change system time to the desired hard-coded date. It works great, but I have to r-click and run as administrator. I'd like to successfully run without r-clicking.
I've tried editing security settings for the service in Local Security Policy, but the result is I don't see a UAC prompt, but the script does not succeed either. It still says
Set-Date : A required privilege is not held by the client
Any thoughts on how to give this privilege to the client? I want the script to run without being prompted for UAC. Thanks.
There really isn't a good way to actual change the time without a prompt. Changing the system time is a privileged operation and doing that without a prompt is tricky (if possible at all).
You could embed the administrator password in a script, have it create a new process as admin and change the time from there. Embedding an admit password in tests though would be a giant red flag.
It's possible there is a security setting somewhere that you could change to make system time alterable by non-admin accounts. I don't actually know if this can be done. If you did this it would require the change on every single computer you run the tests on. Another red flag.
I think a much smoother approach would be to simply abstract away the idea of time in your code behind an interface. Let's say you were using C# you could define the following
interface ITimeUtil {
DateTime SystemTime { get; }
}
In the actual running program you would implement this interface by querying the system time directly as you do today. For the purpose of testing you would mock this interface to return times in the past.
Maybe you can manipulate the token and grant yourself SeSystemtimePrivilege
http://technet.microsoft.com/en-us/library/cc976700.aspx
There is a script floating around the web for doing so here.
https://superuser.com/questions/693620/how-to-restore-the-ownership-of-a-folder-to-trusted-installer-using-silent-com/693627#693627
Using that script you can run this command to enable the privilege (temporarily) then issue your Set-Date to travel backwards in time.
Enable-Privilege SeSystemtimePrivilege
Set-Date "November 5, 1955"
Write-Host "Are You Telling Me You Built A Time Machine Out Of A Delorean"
One possible option might be to use a scheduled task (set to run with hightest privileges) that reads a datetime from a file location, and use your script to write to that file and then run the task.
Related
We have built a project in Enterprise Guide for the purpose of creating a easy understandable and maintainable code. The project contain a set of process flows which run should be done in specific order. This project we need to run on a Linux Server machine, where the SAS Metadata Server is running.
Basic idea is to extract this project into SAS code, which we would be able to run from command line in Linux as a batch job.
Question 1:
Is there any other way to schedule a batch job in Linux-hosted SAS Server? I have read about VBS scripting for scheduling/running batch jobs, but in order this to be done on Linux Server, a installation of WINE is required, which on a production machine which already runs a number of other important applications, is almost completely out of question.
Is there a way to specify a complete project export into SAS code, provided that I give the specific order of running process flows? I have tried out ordered list, which is able to make you a list of tasks to run in order (although there is no way to choose a whole process flow as a single task), but unfortunately, this ordered list itself is later not possible to be exported as a SAS code.
Current solution we do is the following:
We export each single process flow of the SAS EG project into SAS code, and then create another SAS code with %include lines to run all the extracted codes in order that we want. This is of course a possible solution, but definitely not the most elegant one.
Question 2:
Since I don't know how exactly the code is being exported afterwards, are there any dangers I should bear in mind with the solution I chose.
Is there any other, more elegant way?
You have a couple of options from what I'm familiar with, plus I suspect if Dom happens by he'll know more. These answers are based on EG 6.1, which is the current version (ships with 9.4); it's possible some of these things may not be true in earlier versions.
First, if you're running Enterprise Guide from Windows, you can schedule the job locally (on any Windows machine with Enterprise Guide). You're not scheduling the server directly, you schedule Windows to launch an EG process that connects to the server and does its magic. That's how I largely interact with scheduling (because I have a fairly 'light' scheduling need).
Second, from the blog post "Four Ways to Schedule SAS Tasks", options 3 and 4 may be helpful for you. The SAS Platform Suite is designed in part for scheduling, and the options using SAS Management Console to schedule via operating system tools, are both very helpful.
Third, you may want to look into SAS Stored Processes, which should be schedulable. A process flow can be converted into a stored process.
For your specific questions:
Question 1: When you export a process flow or a project, at least in 6.1 you have the option to change the order in which the programs are exported. It's manual, so it's probably not perfect, but it does give you that option. (The code seems to be by default in creation order, which is sub-optimal.) The project export does group process flows together, but you don't have the option of manipulating the order of process flows - you have to move each program around, which would be tedious. It also of course gives you less flexibility if you need to multiply run programs.
Question 2: As Stig Eide points out in comments, make sure your System Option LRECL is > 256 (the default) or you run some risk of code being cut off. In 9.2+ this is modifiable; just place LRECL=32767in your config.sas file.
I want to automate testing of my users' source code files by letting them upload c++,python, lisp, scala, etc. files to my linux machine where a service will find them in a folder and then compile/run them to verify that they are correct. This server contains no important information about any of my users, so there's no database or anything for someone to hack. But I'm no security expert so I'm still worried about a user somehow finding a way to run arbitrary commands with root privileges (basically I don't have any idea what sorts of things can go wrong). Is there a safe way to do this?
They will. If you give someone the power to compile, it is very hard not to escalate to root. You say that server is not important to you, but what if someone sends you an email from that server, or alters some script, to obtain some info on your home machine or another server you use?
At least you need to strongly separate you from them. I would suggest linux containers, https://linuxcontainers.org/ they are trendy these days. But be careful, this is the kind of service that is always dangerous, no matter how much you protect yourself.
Read more about chroot command in Linux.
This way you can provide every running user program with separate isolated container.
You should under no circumstances allow a user to run code on your server with root privileges. A user could then just run rm –rf / and it would delete everything on your server.
I suggest you make a new local user / group that has very limited permissions, e.g. can only access one folder. So when you run the code on your server, you run it in that folder, and the user can not access anything else. After the code has finished you delete the content of the folder. You should also test this vigorously to check that they really cant destroy / manipulate anything.
If you're running on FreeBSD you could also look at Jails, which is sort-of a way of virtualization and limiting a user / program to that sandbox.
User downloads an App (which assume is a game) from server. I need to enforce time constraint on how long a user can run an Application on a system.
eg. Starting from the time of installation, user can use the Application till only 5 days.
My problem is, if I depend on system time/day etc for implementing this logic, user might change the system time and overcome the logic.
Platform: Linux/C++
P.S.: I have to assume a case in which user decides to not connect to internet at all after he downloaded the Application. Since I don't have network access so can't rely on server based storage about Application's installation date/time etc.
Can someone give a clue how this kind of behavior is implemented in Applications which give a trial period of their usage?
Edit:
I am adding the Algo which I am thinking:
At installation time :
At the time of installation store the current system date.
Store this info in an encrypted form into a file DRM.txt
On App startup :
Open the file and decrypt the installation date.
Get the current date from system.
Match if the application is allowed to be executed according to the number of days that have passed since user installed it.
If allowed, start the App else give error msg and return.
Problem:
Let at the time of installation system date is 19/12/2012 and user is allowed to use the App only for 4 days that is till 22/12//2012. Thus, 19/12/2012 is stored into DRM.txt.
After 4 days user changes the system date back to 20/12/2012, then my logic to check will allow this Application to run.
Hope this clarifies what I am trying to say.
This can be achieved through encryption, for example storing a date into an encrypted file, note that this won't prevent reverse engineering, etc, etc, etc
Save and check the time when start and stop the APP.
If the current time is much shorter than the saved time, then you can think it is cheating.
I have a UI app (uses GTK) for Linux that requires to be run as root (it reads and writes /dev/sd*).
Instead of requiring the user to open a root shell or use "sudo" manually every time when he launches my app, I wonder if the app can use some OS-provided API to get root permissions. (Note: gtk app's can't use "setuid" mode, so that's not an option here.)
The advantage here would be an easier workflow: The user could, from his default user account, double click my app from the desktop instead of having to open a root terminal and launch it from there.
I ask this because OS X offers exactly this: An app can ask the OS to launch an executable with root permissions - the OS (and not the app) then asks the user to input his credentials, verifies them and then launches the target as desired.
I wonder if there's something similar for Linux (Ubuntu, e.g.)
Clarification:
So, after the hint at PolicyKit I wonder if I can use that to get r/w access to the "/dev/sd..." block devices. I find the documention quite hard to understand, so I thought I'd first ask whether this is possible at all before I spend hours on trying to understand it in vain.
Update:
The app is a remote operated disk repair tool for the unsavvy Linux user, and those Linux noobs won't have much understanding of using sudo or even changing their user's group memberships, especially if their disk just started acting up and they're freaking out. That's why I seek a solution that avoids technicalities like this.
The old way, simple but now being phased out, is GKSu. Here is the discussion on GKSu's future.
The new way is to use PolicyKit. I'm not quite sure how this works but I think you need to launch your app using the pkexec command.
UPDATE:
Looking at the example code on http://hal.freedesktop.org/docs/polkit/polkit-apps.html, it seems that you can use PolicyKit to obtain authorization for certain actions which are described by .policy files in /usr/share/polkit-1/actions. The action for executing a program as another user is org.freedesktop.policykit.exec. I can't seem to find an action for directly accessing block devices, but I have to admit, the PolicyKit documentation breaks my brain too.
So, perhaps the simplest course of action for you is to separate your disk-mangling code that requires privileges into a command-line utility, and run that from your GUI application using g_spawn_[a]sync() with pkexec. That way you wouldn't have to bother with requesting actions and that sort of thing. It's probably bad practice anyway to run your whole GUI application as root.
Another suggestion is to ask the author of PolicyKit (David Zeuthen) directly. Or try posting your question to the gtk-app-devel list.
We have an embedded linux product with an application which lets the user change different settings through the menu system. These settings include IP address/DHCP and time.
We now run this application as root but this feels wrong, letting the user directly interact with a process run as root.
Which user should we use?
If not root, how do we accomplish the permission issues that arise?
EDIT:
The product does not have a graphical user environment in the classical Gnome/KDE fashion. The menu system mentioned is implemented on an LCD panel on the product itself.
If strict controls are applied to input, there is nothing wrong to run an embedded application as root on Linux.
Anyway, when the underlying OS is something like VxWorks, applications run with maximum privileges as well.
I think the question is: what would happen if something goes wrong? I assume the product would just crash and hang or misbehave in any case? The concept of root vs regular user really only applies if there is something that not being root can protect against... which if all you have is a fixed UI does not seem to be the case.
If the application is the main part of the system, then it makes sense to run it as root.
However, even if there is some extra work, it is worthwhile to uncouple your application with your GUI, so your GUI can run with as a normal user.
This can also help you automate your tests.
This assumes that you're running GNOME.
1) Do what the program "Users and Groups" does. It allows you to see the current settings but requires you to unlock the advanced settings such as managing other users.
2) Use gksu extensively.
I would split the code into parts. Create a user for your interface code. You could name it "interface." Then have it call into root via a daemon or sudo to actually execute the changes that require root. Limit the access so that only approved commands can be run.