New answers tagged

3

A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down. In /etc/default/grub you can uncomment the following line GRUB_DISABLE_RECOVERY="true" And poof! Single User mode is now gone.


3

Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), ...


1

"root" (aka "superuser") is the name of the system administrator account. The origins of the name are a little archaic, but that doesn't matter. Root user has user id 0 and nominally has unlimited privileges. Root can access any file, run any program, execute any system call, and modify any setting. (But see below┬╣). Prior to the invention of the "sudo" ...


0

I solved the problem on Fedora 64 bits by installing the 32 bits sssd-client: dnf install -y sssd-client.i686


1

In RedHat 6 there is an upstart script /etc/init/serial.conf that will ensure the console is designated a secure terminal before starting the getty process, and so ensuring root can login on the console. You may be better off setting the root password to something unknown, thus forcing people to always login as a non-root user and then using sudo to switch ...


1

The simple but accurate explanation is that the vendors of iOS and Android don't want the end-user to have full control over the operating system, whereas the vendors of Unix systems do. It's a design decision by the device vendor. It is technically possible to have iOS or Android systems where the end-user has full control. There is no such iOS-based ...


0

The user that's used in the build step is the user that was used to connect the slave. (For the master, it's the user id under which the master is running). So, create a slave that connects via ssh as the user that you need (possibly to localhost), and then run the jobs on that slave.


0

So I take it GNOME worked prior to updating? If not then your setup may not support GNOME 3, like you said, you can use a different GUI like GNOME on Wayland or install a different one. Otherwise, take a look at /var/log/Xorg.0.log, it will hopefully show any logged errors with GNOME. You can also look at /home/user/.xsession-errors. You can try to ...


2

In order to prevent root or any one from being able to read your files, you need to encrypt them. File Encryption is a very convenient option to look into if you wish to avoid having to deal with complex file system manipulations. Encryption Options: Encrypt ordinary files and prevent everyone but yourself from being able to view them Encrypt Shell ...


0

Yes, there is a way to restrict this behaviour. This behaviour of su is governed by the PAM module (Plugable Authentication Module): You must edit /etc/pam.d/su comment the line : auth sufficient pam_rootok.so like this: #auth sufficient pam_rootok.so after that su from root will ask for the user password.


1

Based on the comment string, it sounds like you don't want to see the \W directory element in the PS1 prompt string (explained here in the bash manual). For your user (mayur) and/or root accounts, edit their .profile or .bashrc (wherever you found the PS1 setting already), and simply remove the \W portion of it, to make it something like: PS1='[\u@\h]\$ ' ...


0

Fixed the problem. Turns out a few libraries necessary for the login binary were missing, namely libcrack.so.2.8.0 and a version of libglib. These were supposed to be located in /usr/lib, and my image's /usr/lib directory was empty. I copied the necessary files in from the /usr/lib directory of a different, working OS (same type and version). So, after ...



Top 50 recent answers are included