Tag Info

Hot answers tagged

11

The major difference between sudo and su is the mechanism used to authenticate. With su the user must know the root password (which should be a closely guarded secret), while with sudo the user uses his/her own password. In order to stop all users causing mayhem, the priviliges discharged by the sudo command can, fortunately, be configured using the ...


8

In Linux/Unix the user with user id 0 is such a super administrator. The user is usually called "root", but the magic is really behind the id and not the name. That user is especially not bound to local file access permissions and can read and write any file. That user also has the ability to change to any other user without needing a password.


6

There are two commands related to root privileges, SUDO and SU. With SUDO, you don't become another user (including root). SUDO has a pre-defined list of approved commands that it executes on your behalf (this addresses what I asked in the comment about how you give selected users selective privileges). Since you are not becoming root or another user, you ...


5

Does your system use Pluggable Authentication Modules (PAM)? Most modern Linux or BSD use PAM. PAM allows you to hook into logins. There are a variety of PAM modules available which might meet your needs, or you can write your own in C. There is even a pam-python* binding which allows you to hook in Python code. Given that you want the daemon to be running ...


4

Working from the vsftpd version 2.2.2, there are two options for keeping users in a chroot jail: chroot_list_enable Just add users to the chroot list e.g. (/etc/vsftpd/chroot_list) that you want placing in a chroot jail. chroot_local_user This will place all local users in a chroot jail, however, if this is set then the chroot_list becomes a list of ...


3

Use the who comand. It lists all logged-in users. It's not just SSH users, it will also list users on the console and directly-connected terminals (if you have any). For SSH users, it will show where they're connected from.


3

It is there for an obvious reason. To quote from this answer, When you are creating an account to run a daemon, service, or other system software, rather than an account for interactive use. Technically, it makes no difference, but in the real world it turns out there are long term benefits in keeping user and software accounts in separate ...


3

groups show you the groups you are in. So the problem is that your process thinks you still are in the now deleted 1001 group, from the deluser myuser 1001 command. You still would get that error message from groups as long as the process you started thinks you are in the group. When doing these kind of things in bash for my own account, I normally start a ...


3

Workaround using GNU parallel. parallel --nonall --sshloginfile .cluster --tag w In my case I use a file .cluster, which contains the hostnames where I want to run the command: $ cat .cluster n04 n05 n06 My output n04 11:19:43 up 110 days, 20:54, 2 users, load average: 0.16, 0.24, 0.25 n04 USER TTY FROM LOGIN@ IDLE JCPU ...


2

Short answer is you can't. If you allow someone (e.g. simth) in sudoer's group, he can issue a sudo su - then become root, then anoter user (e.g. wesson). This is an alternate way of giving root's password to simth. However he (smith) can change root passwd. Notes also that 1) you must specify in /etc/sudoers a line like %sudo ALL=(ALL:ALL) ALL 2) ...


2

This is a known problem, if you ssh as root somewhere and then su to become a normal user: $ ssh root@server # su -l anthon $ screen Cannot open your terminal '/dev/pts/3' - please check. It is e.g. described in these posts from 2005 The solution is to directly login as the user you want the screen session to run as.


2

You can edit the field by editing the file, or you can use usermod -c, although nowadays it is called the comment field in man 5 passwd, this was not always the case, it used to be the GECOS field on UNIX, although that name did not reflect the use it had: providing general information. The proper population is a comma separated list of four (possible ...


2

You don't need systemd for that. know who is logged in since when Use who $ who jimmij tty7 2014-09-25 01:39 (:0) jimmij pts/0 2014-09-25 01:39 (:0) jimmij pts/2 2014-09-28 22:14 (:0) or even better w to get additional information $ w jimmij tty7 25Sep14 12days 4:09m 5:24 sawfish jimmij pts/0 25Sep14 53:43 ...


1

You want to run: who -T | tr -s ' ' | cut -d ' ' -f 1-2 | sort -u Explanation: who -T shows all users and their writeable status ('+' -> you can write to them) tr -s ' ' collapses multiple spaces in who's output cut -d ' ' -f 1-2 only take the first two fields (username + writeable status) sort -u sorts the list and shows only unique occurrences (in ...


1

It might be possible for a sufficiently crafty/devious user to defeat this, but you should be able to catch most logins if you put a command into /etc/profile to notify your daemon.  It could be something simple, like running who am i with output redirected to a fifo that your daemon would read.


1

The file permissions specifically do not allow read, write or execute of that file to the owner (user1). If you were to change the owner to another user, then you would be able to read the file under the group permissions. Excert from File system permissions wiki page Classes ... The effective permissions are determined based on the user's class. ...


1

Have a look at man usermod it shows the -c option which is used to modify the comment field for an account in /etc/passwd. example: usermod -c "raspberry pi user account" pi To update the comments field for the 'pi' user account.


1

The order of operations that causes the expired password prompt is as follows: SSH runs the PAM account stage, which verifies that the account exists and is valid. The account stage notices that the password has expired, and lets SSH know. SSH performs key-based authentication. It doesn't need PAM for this, so it doesn't run the auth stage. It then sets ...


1

You don't need systemd for that … but there's a systemd way of doing it as well, as long as you are running the systemd-logind daemon, or something that provides the same API. First obtain a list of sessions: $ systemd-loginctl list-sessions SESSION UID USER SEAT c89 1000 jdebp seat0 ...


1

Your understanding is wrong. root is all-powerful, and becoming other users is a critical part of root's usefulness.



Only top voted, non community-wiki answers of a minimum length are eligible