I need to use getenv to determine whether the system is X11 or Wayland, and DBUS to realize the screen capture function.
They work well without sudo.
However, when using sudo, getenv gets the wrong value and gdbus cannot locate DBUS.
I'm pretty sure this is a problem with sudo because I tried
echo $WAYLAND_DISPLAY and sudo echo $Wayland_DISPLAY, d-feet and sudo d-feet. They are right when they don't use sudo.
However, due to the requirements of other functions in the program, I have to use sudo. Is there any good idea?
Is there any good idea?
By default, sudo runs the command in a new, fresh environment. From man sudo:
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their
existing environment variables. The security policy may return an error
if the user does not have permission to preserve the environment.
--preserve-env=list
Indicates to the security policy that the user wishes to add the comma-
separated list of environment variables to those preserved from the user's
environment. The security policy may return an error if the user does not
have permission to preserve the environment. This option may be specified
multiple times.
You can list the variables you want to preserve.
sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS,DISPLAY,WAYLAND_DISPLAY,other_variables,etc command
Related
I'm currently doing a project for my school aimed at creating a server in a VM.
One of the requirements of the subject was to install sudo on an emulated Debian Linux, with the following field in the sudoers config file:
Defaults requiretty
The subject line requiring me to set this:
The TTY mode has to be enabled for security reasons.
I know that tty is a command which prints the filename of a terminal that is currently connected to the standard input. However, what I can't see is how this ensures more security for the server.
When requiretty is set, sudo must be run from a logged-in terminal session (a tty). This prevents sudo from being used from daemons or other detached processes like cronjobs or webserver plugins. It also means you can't run it directly from an ssh call without setting up a terminal session.
This can prevent certain kinds of escalation attacks. For example, if I have a way to modify the crontab for a user who has NOPASSWD sudo permissions, I could use that to kick off a job as root. With requiretty, I can't do that...
...easily. This restriction is not particularly hard to circumvent, and so generally isn't all that useful compared to the valid use cases it breaks. Red Hat used to use it, but removed it a few years ago.
I'm using the AI Platform notebook and I want to install cuda because the Tensorflow can't use GPU.
sudo apt-get install cuda-cudart-10-0
Then in the command line it's asking me for password.
(base) jupyter#cuda-10-1-20201008-115420:~/tutorials/stylegan2$ sudo apt-get install cuda-cudart-10-0
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for jupyter:
Sorry, try again.
I don't recall I gave it any password while setting it up. Is there a default password for it?
To answer the first question, our Notebooks provide TensorFlow and when you create it, you can select to install Nvidia Driver automatically. Probably this option was missed during instance creation.
With respect to the second question, from the output, seems to be that you are in Jupyter Terminal.
Jupyter Notebooks provides access to Instance OS which could be Debian 9/10 or we support Ubuntu now. Jupyter Terminal process is running as jupyter user. While you can still run process as root. I would suggest you that you login via SSH and run commands directly from there. If you create the Notebook via UI we now provide OS login feature which allows you to access instance via SSH with IAM permissions hence your Google Cloud user account. If you are not sure of any of this, please contact your IT admin.
What do you think sudo does? If this is your first time using a Linux system, know that prepending every command in Linux with sudo is same as typing cmd in the windows run box and then pressing shift+enter. sudo is a way to tell the OS that I need admin rights (or in Linux's case, root permissions). So, it is bound to ask you for the password.
The password it is asking for is your account password. Also, it is usually a good idea to set up the root password when in first use. To set it up, drop into the root prompt from your user account using sudo su. Then type in passwd to set up a new password for the root user. Log out, and restart the machine.
Do not forget that root account has the ultimate privileges, and unless absolutely necessary, it is always better to prepend the command with sudo instead of dropping into the root prompt.
PS: A hint: sudo <command> followed by the caller's password is same as su -c '<command>' followed by the root account's password
You also might want to take a look at fakeroot
Which linux distro are you on? Like Kali has default password as root or toor or kali depending on version
Till now I had been using become: true for running a task as root user (whenever required).
But this time the hardware I am trying to control is a bit different. Its a VM controlled by a different team, where the sudo operations are restricted. You are not allowed to do sudo su either. Simply, sudo is not permitted.
In case you want to switch to a root shell, you have to execute a command (which maps to a binary) sudo rootshell (the only operation permitted with sudo). This is done in order to log sudo attempts.
Now, this fails my playbook as I cannot use become: true in case I want to install some package. Does ansible playbook provide any solution for this? I tried shell: sudo rootshell and failed, but even if it would have worked I don't feel the session will be maintained across tasks.
I'm quite new to Linux. I remember using a tutorial were you were able to declare your sudo (+password) at the start and then use terminal without having to do sudo or import your password again.
I.e.
Sudo yum-get update -> yum-get update.
Sorry if this is a very obvious question, I honestly don't remember where the tutorial was from, and how to do it again.
ps - if it helps, I'm on a RedHat Distro, but go between Debian and RedHat.
You can use su. This way you are changing the ownership of the session to root (by default, you can also change to any other user on the system) and therefore you will be able to avoid the sudo.
Here you can find some more information on the command.
You may use
sudo -i
It acquires the root user's environment and kind of simulates a login into the root account
I've got an SVN instance installed on a free EC2 AWS server. In short: I'm using LAMP.
Using what I read in this article and encountered the "you need a TTY" error as mentioned in the comments. I followed the second resource and it cleared the error message, but doesn't seem to be executing the script. When I manually run the script, however, it works.
Any clue what I'm missing?
When I followed the second resource to fix the TTY error I changed the contents of my /svn/repository/hooks/post-commit script from:
#!/bin/bash
sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
to:
#!/bin/bash
su –session-command=”/usr/local/bin/svn-post-commit-update-mysite 1>&2″ dynamic &
First possible issue:
You cannot rely on the value of the $PATH variable inside the hook. This means you need to specify complete paths for all executables.
In particular, "su" is a program located in "/bin/sh" in most distributions. To be sure, type
type su
Next possible issue:
Is your subversion server being run as root? su will try to ask for password if run by other users, and will fail if it's not being run interactively - even if the user is in the sudoers file!
If you are using Apache+DAV, this means the apache service must be run as root for this to work (instead of www-data), which is a serious security problem.
You probably don't need to use su or sudo at all if all of the files are owned by the same user (www-data, for instance). You can change the ownership of the site files with something like
sudo chown -R www-data:www-data /var/www/<my-project>
And then remove the sudo and su from both the hook and the svn-post-commit-update-mysite file.
My best guess would be that something in your script depends on the PATH environment variable. Subversion runs hooks in an empty environment for security reasons. So you need to either setup the environment in your shell script or use absolute paths.
You might want to read the Subversion book entry on implementing hook scripts. The particular issue I mentioned is explained in the information block.