I currently have an Asus c300 chromebook. Since it doesn't have legacy boot, I'm using crouton to get a more standard command line environment. I was able to install gcc very easily in the chroot environment. It works very well under chroot.
Since the underlying hardware is the same, I thought the resulting executable should work for chromebook, without me being in the chroot environment. If true, I thought I could go into the chroot environment, compile whatever program I want/need, and exit back out to the regular environment and use it.
I tried it with a simple hello world program. When I tried to run the executable, I got the following error:
bash: ./a.out: Permission denied.
I tried to run it with sudo, and I get a similar error:
sudo: unable to execute ./a.out: Permission denied.
I even used su to login as root, and I still could not run the program (got the first error).
I thought su/sudo would override any kind of permission restriction. But, it's apparently not the case on the chromebook.
What am I missing? Is what I want to do possible?
EDIT: File permission was already set to 777.
You might simply have to change the permissions of the file or check the files ownership. umask determines weather or not a file that is created gets execute permissions by default. What does -ls -lat on the file reveal?
Also try running
chmod +x ./a.out
You can find more details of error with strace command
use:
strace ./a.out and check output.
I suppose you have different env (path and LD_library_path) under the chroot.
Related
I'm setting up a new remote host and every time i initiate it i get the following error output: Any feedback or direction on how to resolve this issue?
Pseudo-terminal will not be allocated because stdin is not a terminal.
Linux Destiny 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
mesg: ttyname failed: Inappropriate ioctl for device
bash: cannot set terminal process group (3202): Inappropriate ioctl for device
bash: no job control in this shell
mesg: ttyname failed: Inappropriate ioctl for device
Installing...
Downloading with wget
WARNING: tar exited with non-0 exit code
Found running server...
*
* Reminder: You may only use this software with Visual Studio family products,
* as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
*
cat: /root/.vscode-remote/.473af338e1bd9ad4d9853933da1cd9d5d9e07dc9.log: No such
file or directory
Server did not start successfully. Full server log:
cat: /root/.vscode-remote/.X.log51ec4692-
4da4-4ec0-b613-5a3563034cf1====
: No such file or directory
"install" terminal command done
Received install output: : No such file or directory
Failed to parse remote port from server output: : No such file or directory
If the server fails to shut down properly, sometimes it leaves dangling lockfiles. This can cause startup to fail and produce the "Failed to parse remote port from server output" error message. In this case the solution is to simply to delete the lockfiles:
.vscode-server/bin/[:xdigit:]*/vscode-remote-lock.*
Fixed the issue. It appears I had 2 other server agents running incorrectly. I killed both server agents using kill (PID) and removed ".vscode_remote" directory from user home directory. Then i reinitialized remote-ssh from vscode. Successfully connected!
On remote machine you do not have a tar installed. It's in log output
Installing... Downloading with wget
WARNING: tar exited with non-0 exit code
so under a root run:
apt-get install tar
or with sudo, if you have a user with sudoers configured:
sudo apt-get install tar
I also got the same issue and my workaround was to provide proper rights to the home or user folder, so vscode can create a remote folder and do the required installation on it.
Example :
sudo chmod -R 777 home/
In this case, I have provided all rights to my home folder and It worked like a charm for all the users.
I ssh'd onto the remote server (linux) and then deleted both directories as follows:
$ rm -r .vscode-server.backup2022-04-03T16:20:18-05:00
$ rm -r .vscode-server
In case someone else encounters the same issue - I had an instance where remote target had no space left on device. After extending root volume of target machine, connection worked fine.
I had the same issue because vscode was looking for my .vscode-server directory in the wrong location (it was in a custom location due to restrictions on where files can be saved). This can be fixed by using How to change vscode-server directory. Specifically add:
"remote.SSH.lockfilesInTmp": true,
"remote.SSH.serverInstallPath":{
"hostname":"/path/to/.vscode-server/.."
}
To your settings.json
In my case, it wasn't working because of server asking for new password when starting a session. What I did was to open a new default terminal (not VSC terminal but your OS default terminal like ZSH, CMD, and so on). And I used the ssh command to login. I logged in successfully and changed the password. Then I tried connecting with the new password and it worked because the server didn't asked for password change now.
Command:
ssh username#IP
Enter password and you'll get asked to change the password. Change the password and try connecting again with new password using SSH VSC extension.
If yout authorize by ssh-key - also check the value of User parameter in VsCode ssh config. User must have matching key in ~/.ssh/authorized_keys on remote host.
#Sachin's answer directed me in the right direction, VSCode needs permissions in order to create some files, but instead of giving 777 permissions to your home folder (which can be dangerous) you can just chown the user that wants to log in (the user for me was ubuntu):
sudo chown -R ubuntu /home
I also got the same issue and my workaround was to provide proper rights to the home or user folder, so vscode can create a remote folder and do the required installation on it.
Step 1: Add port to your config file :
Host hostname
Port 22
User username
Step 2 : Go to File->Prefrences ->Open settings.json fle
Search for lockfilesInTmp
and check the box next to that
I'm trying to remotely launch and debug a new process with lldb without much success.
Attaching to an already launched process works well by running these commands:
process connect <url>
process attach -P gdb-remote --pid <pid>
But if I want debugserver to launch the executable by itself I'm running into troubles. Especially, I have no clue what arguments should I pass to target create.
According to this page LLDB "will transparently take care of [..] downloading the executable in order to be able to debug", yet target create seem to always require a local file. If I specify the remote file via -r I get either unable to open target file or remote --> local transfer without local path is not implemented yet errors. If I set the target to a local file (such as a local copy of the remote's loader executable) without using -r, then attempt to run process launch -p gdb-remote -s <remote path> LLDB will attempt running the local path on the remote machine and fail.
What are the correct commands I need to use in order to launch a remote process?
After contacting LLDB's mailing list Greg updated the documentation page, which now clearly explains what I have to do (Specifically I was missing the script lines, which appear to be the correct way to set the remote executable path)
I have compiled a c program into an executable that I would now like to integrate into the applications menu in Debian 7.4 XFCE. In order to run the application under normal circumstances, I am required to type
sudo myprogram
Now I have created my .desktop file and placed it in /usr/share/applications
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=myprogram
Comment=configuration loader
Exec=sudo loader
Icon=/usr/share/icons/hicolor/48x48/apps/myprogram.png
Terminal=false
Categories=Development;IDE
The item is added to my applications menu as expected, and the icon shows up properly. The problem, however, is that double clicking the menu item to launch the application does nothing.
If I navigate to /usr/bin (where I have placed my executable) and type "sudo myprogram", the program launches as expected.
What can I do to fix this issue and get the program to launch from the menu? Perhaps /usr/bin is not the correct place to put it, or I have the incorrect Exec command. I greatly appreciate the help.
I ended up using (after installing gksu)
Exec = gksu myprogram
this launches a graphical sudo prompt, which is sufficient for my needs.
This is what the setuid bit in the permissions is for. It makes executables run with permissions of the file owner. This only works on actual executables, not on shell scripts!
sudo chmod u+s myprogram
sudo chown root myprogram
./myprogram # now runs as root
Please be careful when using this as it will always execute that program as root no matter who executes it. You can limit access by setting it to your usergroup and deny all execute.
chgrp "${USER}" myprogram # provided you have individual groups set up
chmod a-x myprogram # deny all execute
This approach does not need additional installation of packages.
Terminal=true opens a new terminal window which runs
sudo -i to ask for the password.
Then, using sh to run the program, the Terminal is closed and myprogram runs in the background because it has a & at the end.
[Desktop Entry]
Type=Application
Name=...
Exec=sudo -i sh -c "myprogram &"
Terminal=true
Request: Please report if it works under your OS.
Tested under:
Xubuntu
The pkexec solution from askubuntu:
Exec=pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY APP_COMMAND
Try adding this to .desktop
Path=/path/to/myprogram
I am using windows XP operating system and cygwin is installed in my C drive.
I need to login to cygwin directly to my directory path which contains a makefile and also a bash script called build.sh in the same directory. So i modified the original cygwin.bat file and added the line as shown below.
#echo off
C:
chdir C:\cygwin\bin
bash --login "/cygdrive/E/scheme_31july/build/build.sh"
When i double click on this bat file i could see my script executing but not on cygwin shell but on windows cmd shell as a result I get errors for "make" command like "No rule to make target" as make comes bundled with cygwin.
And when I explicitly login to cygwin using default cygwin.bat file and execute my script by giving following commands in cygwin shell the script executes without errors.
Basically I want to write a bat file so that I can keep it anywhere in my PC and instead of manually openeing the cygwin prompt and typing commands like:
$ cd /cygdrive/E/scheme_31july/build/
$ sh build.sh
it should happen automatically. I sit possible to do so.
Regards,
Harshit
No rule to make target sounds more like make being executed in the wrong directory. make itself seems to be available and running as intended.
Try this:
bash --login -c "cd /cygdrive/E/scheme_31july/build/ && sh build.sh"
This should start a --login session (which should give you access to all the settings and tools you'd expect in a cygwin prompt environment), then execute the given shell command, which is the cd and sh you asked for. You could also write those two lines to a separate script file, and pass the name of that to bash instead of the full path to build.sh.
You could also try to cd into C:\scheme_31july\build in the bat file and then execute bash from there. Not sure whether bash will try to change path upon entering the login session. You can try whether things work without the --login, both for this approach and the one above.
#echo off
C:
cd C:\scheme_31july\build
C:\cygwin\bin\bash.exe ./build.sh
I'm not sure whether you want the session to turn interactive after that or not. In the above case, bash will terminate after the script completed, and might even close the window. You might have to add a read into build.sh to avoid that. If you want bash to turn interactive after executing some command, you can try using the --rcfile option of bash to execute some commands and then turn interactive.
I'm programming application using libpcap. when I debug the application in normal mode, pcap cannot get the network device. it seems that I have to debug the application in root.
How can I debug the application in root? I have the root password.
I think eclipse has such an option that can add root for the debugging application,but I don't know how to do it.
please help.
Enable your user to run gdb as root without being asked for any
password:
sudo visudo
Add the following line after all other rules:
<youruser> ALL=(root) NOPASSWD:/usr/bin/gdb
Create or modify a debug configuration in eclipse to run gdb as root
e.g. in Run > Debug Configurations > C/C++ Application > YourProject Debug:
change Debugger > Main > GDB debugger from gdb to sudo -u <youruser> gdb
Update (and warning!):
In his comment nategoose pointed out that this answer should come with a warning:
Enabling a user to use sudo for gdb like suggested in my answer in fact gives admin privileges to him/her which in many cases might be an undesired side effect. I therefore consider the answer appropriate in an environment where it's not assumed that the user would try to harm the system (e.g. it's your own personal computer or a virtual machine)
For a multi-(non-trusted)-user environment I think it might be a better idead to utilize unix' file capabilities to enable gdb to debug an application without the need of admin privileges
You can use gdbserver on localhost to attach a existing process, the following is the command line:
sudo gdbserver :<listening port> --attach <pid>
Or you can create a new process using gdbserver:
sudo gdbserver :<listening port> <process executable>
Then you can create a debugging configuration in Eclipse, in the debugger tab, the debugger item, select gdbserver, and input the listening port in the connection tab in the bellow.
Launch Eclipse with sudo (just for completeness: http://www.eclipse.org/forums/index.php?t=msg&goto=516838&)
Update: Follow xmoex solution. If you run Eclipse as root (ie. using sudo) your files will be root-owned... which you probably don't want.
Another solution is to grant you (or the gdb executable) the rights to make some pcap captures as mentioned here. With something like this :
setcap cap_net_raw,cap_net_admin=eip /usr/bin/gdb
you should be able to allow to capture packets to gdb without being root.
Here's how I did it:
Create a C/C++ Remote Application
On the target, make sure your sudo does not prompt for a PW
Look at Debug Configurations → Debugger → Port number
Edit Debug Configurations → Main → Commands to execute before application
Change to:
sudo gdbserver :<port number> <path to application>;exit #
This will basically run the gdbserver that would normally be executed by eclipse inside the sudo, the trailing '#' will keep the eclipse command from executing.
this question was asked a long time ago but if this will help to anybody I open a bug in bugzilla and this short thread solved the problem:
bugzilla bug
From the console in the directory with your executable:
sudo gdb ./my_program
If eclipse supports remote debugging then you could do that even though it is running locally.
From the console:
sudo gdbserver localhost:<port_number> ./my_program
And then tell Eclipse the address (localhost and the port number you chose).
Oh yeah, you said the reason you were doing this was because you were using libpcap, so you may not want to use remote debugging over TCP because you may end up capturing your debugging connection packets in addition to your other network traffic.
In that case you do your remote (but really local) debugging over a serial port. I have never done this on a local machine, but you could use two actual serial ports (attaching them though a null modem) or try using a psudoterminal:
sudo gdbserver /dev/ptmx ./my_program
This will create the psudo-terminal under /dev/pts/ but you'll have to figure out the name of it, and it might also create it with restrictive permissions. You can get around those. Unless you are running lots of terminal windows as root, it is not likely that you have many entries under /dev/pts that belong to root, so take note of the one that does after running the above command and then sudo chmod or sudo chown it to make it usable for your normal user and then tell your debugger to use that as your serial connection to your remote debugging target.
easiest way, try sudo ./eclipse, then debug as usual