When using the Shipit automation engine I found that trying to execute commands with "sudo" from an user other than root (let's call it "devuser") results in the connection closing without the command being executed.
This is a command that I'm trying to execute:
shipit.remote('sudo pwd');
Note that, on the target machine, "devuser" can execute everything with "sudo", without being asked his/her password (it's a choice of the target system).
Also note that everything invoked without "sudo" (and that obviously doesn't need elevated permission) gets executed prefectly fine by Shipit.
E.g.this one works just fine:
shipit.remote('pwd');
The question at this point is: am I doing something wrong or is it this way by design (e.g. to avoid privileges escalation)?
If it's the latter: is there a way to work this limitation around?
simple hack for that is to set user inside each command that you are running with shipit. This is little overhead especially if there are a lot of commands but it will do the trick. Command for that is :
su - <user> -c "<command>"
In your case :
shipit.remote('su - devuser -c "pwd"');
You were on right track with your example.
Best regards,
Nikola
Related
Is there any possibility to connect to an SSH server using /ssh:user#server with read-only access, even if the account has write access? I need this to prevent accidental write.
Here is the function I use to connect:
(defun connect-b2b ()
(interactive)
(find-file-other-window "/ssh:user#server:/")
buffer-read-only)
(global-set-key (kbd "C-c C-d") 'connect-b2b)
Note that buffer-read-only does not help, neither does vc-toggle-read-only.
Update: Just to be clear what I want to achieve, I have an account with read+write access, however since this is a business critical server I wanted to prevent accidental changes. Unfortunately I cant change permissions on the user account itself, therefore I wanted to enforce this locally.
Third suggestion: Use sshfs to provide the remote filesystem locally, and mount it read-only, and then point Emacs at that.
That way you're not subject to all of the pitfalls of being able to run commands directly on the remote server as a user who has write-permissions.
If I've interpreted the question rightly, directory-local variables are a potential workaround. This would be overridden if there were dir-local configs nearer to the path in question, however, so YMMV.
(dir-locals-set-class-variables
'read-only
'((nil . ((buffer-read-only . t)))))
(dir-locals-set-directory-class "/ssh:user#server:/" 'read-only)
I'm still able to for example touch a file in the specified directory.
That's got nothing to do with Emacs. You're asking for Emacs to employ OS-level access controls, which it can't do, because it's not the OS. In your case it's not even running on the same machine.
You need to create a new user with more limited access, and connect as that user instead.
I have two Access databases that I'm opening on the same computer. In one, running this in the immediate window works as expected (opens Notepad):
Shell "notepad.exe"
In the other, I get this error instead:
Run-time error '5': Invalid procedure call or argument
I have not been able to come up with any shell command that will run successfully in that second database. No matter what, I get that error.
What is going on here? Could there be a security setting coming into play? Or perhaps one is an older version?
Edit - More Info
When I go to the definition of Shell in the malfunctioning database, it goes to VBA.Interaction.Shell.
I get the correct IntelliSense tooltip for Shell.
I tried VBA.Shell "notepad.exe" and VBA.Interaction.Shell "notepad.exe" without success (same error).
Here are the references that are checked in both databases:
Decompiling did not help.
The culprit was our anti-virus software! UGH!
Why did it work in one database and not the other then? I'm told that years ago, anti-virus exceptions were made for my computer for the one database but not the other.
I recommend that any others who encounter this problem check their anti-virus logs/policies. Also, running the database from another computer with different policies in place might shed some light on the issue faster. In this case, when I used remote desktop to log into a server, I was able to call shell successfully.
Just found that SQLPLUS would parse the first line of a sql script as connect string if I do not include the credentials when invoke sqlplus in the terminal, details are listed below:
I have a sql script named runme.sql:
scott/tiger#//localhost:1522/orcl
select * from dual;
exit;
If I invoke sqlplus as sqlplus #runme.sql , sqlplus could parse the first line and connect to database and run the sql. Can anyone point me to the documentation for this if there is any ? Also what are the advantages for supporting this syntax ?
The documentation is usually a good place to start. Note the warning if you supply the username/password on the command line; providing at least the password when prompted is more secure, and particularly in Unix-type environments means the credentials don't appear in the output of a ps command.
Putting either the password or both the username and password in a script automates that, but of course you have to then ensure that the script can't be viewed by anyone who shouldn't know the credentials.
As LalitKumarB notes in a comment, hardcoding the password anywhere is a security risk. If you're running scripts interactively then allow the slight inconveince of being prompted each time. (Which isn't really inconvenient when compared to the damage that could be done from the credentials being misused, and subsequent inconvenience of recovering, and/or finding a new job). If the script isn't being run interactively then use the scheduler rather than, say, cron. You can also use Oracle Wallets for greater security without so much inconvenience.
Specifically for your query about it parsing the first line, the documentation says:
If you do not specify logon but do specify start, SQL*Plus assumes that the first line of the script contains a valid logon.
In this context 'start' is the same as using # on the command line to supply the script name.
I'm running a process in a screen (on Ubuntu 13.10, if it matters). I can execute a command within that screen with:
screen -p 0 -X eval 'stuff \"$command\"\015'
I'm not 100% sure what this command is doing to begin with, though it's functioning correctly. The reason behind it is I'm running a Minecraft server (still) and this screens in to the correct screen, and throws the command on the running command line. So that's good, so far.
But what I'd like is to be able to run this command with a return value. So for example, if I were to run a "list" command, it'd tell me how many people and who is online, but I need to capture that output and put it somewhere.
Anyone know of a way to accomplish this? I can't tell the minecraft server command line to redirect the output somewhere else since it doesn't have direct command line access, so the only way I could do this would be to grab all output of the screen while I'm connected ... but I'm not sure if that's possible.
I think you may be able to view the logs? can you not view a running log of the server ?
On development everything works great. On production however, this line of code in a controller is no working:
output = `mclines #{paramFileName} #{logFileName} #{outputFileName}`
where mclines is a c program, and the rest are names of files. mclines is not executed on the production server, but it does on my laptop. I have no idea about what to fix. Have been trying different things for hours, but the truth is that I'm quite lost. In production the ssl in on, that's the only major difference.
If I execute the command on the shell, it gets executed. When I say it doesn't gets executed is because the first thing it should do is print some info in a file, and it doesn't. The server -as my laptop- is running ubuntu, but I have no idea about what logs could be usefull to read. systemlog had nothing usefull.
Any ideas that can lead to find the culprit are welcome.
Make sure mclines really exists on the production server, and use the full path to the mclines executable, as in
output = `/full/path/to/mclines #{paramFileName} #{logFileName} #{outputFileName}`.
Reference this
Try to print out your exit status code as:
$?.to_i
after the command...
or as pointed out in this link you can always use popen3/popen4 for better handling of input/output for system commands...