Ubuntu Server - administrative user rights. User management Display all privileged users

Let's say I'm a new user of Ubuntu Linux 16.04.xx LTS. I immediately have a number of questions. How to create a new sudo user on my server? How to add new user to sudoer file using parameter command line on Ubuntu?

On Linux (and Unix in general) there is a superuser called root. The root user can do anything and everything, and thus the normal use of the system can become very dangerous. You can enter the command incorrectly and destroy the system. The sudo command allows an authorized user to run a command as the superuser (root user) or another user as specified in the security policy. Often sudo is used on servers to grant administrative rights and privileges to regular users. This quick tutorial will show you how to create a sudo user on Ubuntu.

A few steps to follow in order to create a sudo user on Ubuntu

More about admin group and sudo group on Ubuntu server

Members of the administrative group can be granted root privileges. All members of the sudo group run any command on ubuntu server. So just add the user to the sudo group on the Ubuntu server. The capabilities of the admin group have been significantly reduced since Ubuntu 12.04 and later. Therefore, the admin group no longer exists, or it is simply used in Ubuntu 12.04 or later. Reason why this works:

# grep -B1 -i "^%sudo" /etc/sudoers

$ sudo grep -B1 -i "^%sudo" /etc/sudoers

# Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL

Let's look at some practical examples.

How to add a new user named vivek to sudo using the command line?

Open a terminal or login to your remote server:

$ ssh [email protected]$ ssh [email protected] { [email protected]:/root) #

# adduser vivek

$ sudo adduser vivek

Figure 01: How to add a new user on Ubuntu

Examples of possible data outputs:

How to create sudo user in Ubuntu for vivek account

Enter the following command:

# adduser vivek sudo

OR use the usermod command to add a user to a group on Linux:

# usermod -aG sudo vivek

$ sudo usermod -aG sudo vivek

$ sudo adduser vivek sudo

Examples of possible data outputs:

Figure 02: Add user vivek to sudo to get admin rights

Confirm the new user and group member with:

$id vivek

Examples of possible data outputs:

Figure 03: Show user and group information

The vivek user can now login using the ssh command as follows:

$ ssh [email protected]

Make sure vivek can use the sudo command:

$ sudo cat /etc/sudoers

The first time you use the sudo command, you will be prompted for a password account vivek. So enter the password vivek to gain root access. Any type of command with sudo must be run with root privileges for the vivek account. To get a root shell, type:

$ sudo -s

Examples of possible data outputs:

Figure 03: Testing sudo access for the vivek user account

And so you did it. You can now allow other users to run sudo on the Ubuntu server and give users admin rights.

In the operating room Linux system There are many great security features, but one of the most important is the file permissions system. Linux, as a follower of the ideology of the Linux kernel, unlike Windows, was originally designed as a multi-user system, so file permissions in linux are very well thought out.

And this is very important because local access to files for all programs and all users would allow viruses to destroy the system without any problems. But new users may find the new file permissions in linux very complicated, which are very different from what we are used to seeing in Windows. In this article, we will try to understand how file permissions work in linux, as well as how to change and set them.

Initially, each file had three access parameters. Here they are:

  • Reading- allows you to get the contents of the file, but not for writing. For a directory, allows you to get a list of files and directories located in it;
  • Recording- allows you to write new data to a file or change existing ones, and also allows you to create and modify files and directories;
  • Performance- you can't execute a program if it doesn't have an execute flag. This attribute is set for all programs and scripts, it is with the help of it that the system can understand that this file needs to be run as a program.

But all these rights would be meaningless if applied immediately to all users. Therefore, each file has three categories of users for which you can set different combinations of access rights:

  • Owner- a set of rights for the owner of the file, the user who created it or is currently set by its owner. Usually the owner has all rights, read, write and execute.
  • Group- any group of users that exists in the system and is associated with the file. However, this can only be one group, and is usually the owner's group, although a different group can be assigned to the file.
  • Rest- all users, except for the owner and users included in the group of the file.

It is with the help of these permission sets that file permissions are set in linux. Each user can only have full access to files that he owns or that he is authorized to access. Only the Root user can work with all files, regardless of their permission set.

But over time, such a system was not enough and a few more flags were added that allow you to make files immutable or execute on behalf of the superuser, we will consider them below:

Special file permissions in Linux

In order to allow ordinary users to execute programs on behalf of the superuser without knowing his password, such a thing as SUID and SGID bits was invented. Let's take a closer look at these powers.

  • SUID- if this bit is set, then when the program is executed, the id of the user from which it is launched is replaced by the id of the file owner. In effect, this allows regular users to run programs as root;
  • SGID- this flag works in a similar way, only the difference is that the user is considered a member of the group with which the file is associated, and not of the groups to which he actually belongs. If the SGID flag is set on a directory, all files created in it will be associated with the group of the directory, not the user. This behavior is used to organize public folders;
  • sticky-bit- this bit is also used to create shared folders. If set, users can only create, read, and execute files, but cannot delete files owned by other users.

Now let's look at how to view and change file permissions in linux.

How to View File Permissions in Linux

Of course, you can look up file permissions in Linux with file manager. All of them support this feature, but this way you will get incomplete information. For the most detailed information about all flags, including special ones, you need to use the ls command with the -l parameter. All files in the directory will be listed, and all attributes and bits will be shown there.

To find out the rights linux file run the following command in the folder where this file is located:

For file permissions in linux, dashes are responsible here. The first is the file type, which is discussed in a separate article. Then there are groups of rights, first for the owner, for the group and for everyone else. Only nine dashes for rights and one for type.

Let's take a closer look at what the conditional values ​​of the permission flags mean:

  • --- - no rights at all;
  • --x- only file execution is allowed, as a program, but not changing or reading;
  • -w-- only writing and modifying the file is allowed;
  • -wx- modification and execution is allowed, but in the case of a directory, you cannot view its contents;
  • r--- read-only rights;
  • r-x- read-only and execute, no write access;
  • rw-- rights to read and write, but without execution;
  • rwx- all rights;
  • --s- SUID or SGID bit is set, the first is displayed in the field for the owner, the second for the group;
  • --t- sticky-bit is set, which means users cannot delete this file.

In our example, the file test1 has typical permissions for programs, the owner can do everything, the group can only read and execute, and everyone else can only execute. For test2, the SUID and SGID flags are additionally set. And for the test3 folder, Sticky-bit is installed. The test4 file is available to everyone. Now you know how to check the permissions on a linux file.

How to change file permissions in Linux

To change file permissions on linux, you can use the chmod utility. It allows you to change all flags, including special ones. Let's look at its syntax:

$ chmod options category action flag file

Options now will not interest us, except perhaps only one. With the -R option, you can force the program to apply changes to all files and directories recursively.

  • u- the owner of the file;
  • g- file group;
  • o- other users.

The action can be one of two, either add the "+" flag, or remove the "-" flag. As for the permissions themselves, they are similar to the output of the ls utility: r - read, w - write, x - execute, s - suid / sgid, depending on the category for which you set it, t - sets sticky-bit. For example, all users have full access to the test5 file:

chmod ugo+rwx test5

Or we will take away all rights from the group and other users:

chmod go-rwx test5

Let's give the group the right to read and execute:

chmod g+rx test5

Read-only for other users:

For the test6 file, set the SUID:

And for test7 - SGID:

Let's see what happened:

As you can see, changing file permissions in linux is very easy. In addition, you can change the basic rights using the file manager.

conclusions

That's all, now you know not only what file permissions are in linux, but also how to view them, and even how to change them. This is a very important topic, which is really worth understanding for beginners in order to use their system more fully. If you have any questions, ask in the comments!

At the end, I want to offer a good video about access rights in linux:

Since Linux is a multi-user system, the issue of organizing access control to files and directories is one of the essential issues that should be addressed by operating system. Access control mechanisms designed for UNIX systems in the 70s (perhaps, however, they were proposed by someone earlier), are very simple, but they turned out to be so effective that they have existed for more than 30 years and to this day successfully fulfill the tasks facing them.

Access control mechanisms are based on user names and user group names. You already know that in Linux each user has a unique name under which he logs in (logged in). In addition, a number of user groups are created in the system, and each user can be included in one or more groups. The superuser creates and deletes groups, he can also change the membership of a particular group. Members different groups may have different file access rights, for example, the administrators group may have more rights than the programmers group.

The inode of each file contains the name of the so-called owner of the file and the group that has rights to this file. Initially, when a file is created, the user who created the file is declared its owner. More precisely, the user on whose behalf the process that creates the file is launched. The group is also assigned when the file is created, by the group ID of the process that creates the file. The owner and group of the file can be changed in the course of further work using the commands chown and chgrp(more about them will be discussed later).

Now let's run the command again ls-l. But let's set it as an additional parameter the name of a specific file, for example, the file that specifies the command itself ls. (Pay attention, by the way, to this possibility of the command ls-l- get information about a specific file, and not about all the files in the directory at once).

$ ls -l /bin/ls

You can see that in this case the file is owned by the root user and the root group. But now we are more interested in the first field in the output of this command, which determines the file type and file permissions. This field in the example is represented by a string of characters -rwxr-xr-x. These characters can be roughly divided into 4 groups.

The first group, consisting of a single character, defines the file type. This symbol, in accordance with the possible file types discussed in the previous section, can take on the following meanings:

    - = - regular file

    d=- directory;

    b=- block device file;

    c=— character device file;

    s=- domain socket (socket);

    p=- named pipe (pipe);

    l =- symbolic link (link).

This is followed by three groups of three characters each, which determine the access rights to the file, respectively, for the owner of the file, for the user group that is mapped given file, and for all other users of the system. In our example, the permissions for the owner are defined as rwx, which means that the owner ( root) has the right to read the file (r), write to that file (w), and execute the file (x). Replacing any of these characters with a dash will mean that the user is deprived of the corresponding right. In the same example, we see that all other users (including those who are included in the group root) are deprived of the right to write to this file, i.e. they cannot edit the file and generally somehow change it.

Generally speaking, access rights and information about the file type in UNIX systems are stored in inodes in a separate structure consisting of two bytes, i.e. 16 bits (this is natural, because the computer operates with bits, not the characters r, w, x). Four of these 16 bits are reserved for an encoded record of the file type. The next three bits define special properties executable files, which we will talk about a little later. And finally, the remaining 9 bits determine the file permissions. These 9 bits are divided into 3 groups of 3 bits. The first three bits define the user's permissions, the next three bits define the group's permissions, and the last 3 bits define the permissions of all other users (that is, all users except the file owner and file group).

In this case, if the corresponding bit is 1, then the right is granted, and if it is 0, then the right is not granted. In the symbolic form of rights notation, the unit is replaced by the corresponding character (r, w or x), and 0 is represented by a dash.

The right to read (r) a file means that the user can view the contents of the file using various viewing commands, for example, the command more or with any text editor. But if you edit the contents of a file in a text editor, you won't be able to save the changes to the file on disk unless you have write (w) permission to the file. Execute permission (x) means that you can load the file into memory and try to run it as an executable program. Of course, if the file is not really a program (or a shell script), then it will not be possible to run this file for execution, but, on the other hand, even if the file is really a program, but the right to execute is not set for it, then it will not work either. will start.

So we learned which files in Linux are executable! As you can see, the file name extension has nothing to do with it, everything is determined by setting the "executable" attribute, and the right to execute may not be granted to everyone!

If you run the same command ls-l, but specify not a file name, but a directory name as the last argument, we will see that access rights are also defined for directories, and they are set by the same rwx characters. For example, by running the command ls -l /, we will see that the bin directory corresponds to the line:

Naturally, in relation to directories, the interpretation of the concepts "right to read", "right to write" and "right to execute" changes somewhat. Read access to directories is easy to understand if you remember that a directory is just a file containing a list of files in that directory. Therefore, if you have the right to read the directory, then you can view its contents (this is the list of files in the directory). The write right is also clear - having such a right, you can create and delete files in this directory, that is, simply add to or delete from the directory an entry containing the name of a file and the corresponding links. The right to execute is less intuitive. In this case, it means the right to go to this directory. If you, as the owner, want to allow other users to view a file in your directory, you must give them permission to access the directory, i.e., give them "execute directory permission". Moreover, you need to give the user execute permission for all directories above this directory in the tree. Therefore, in principle, for all directories, by default, the right to execute is set both for the owner and group, and for all other users. And, if you want to close access to the directory, then deprive all users (including the group) of the right to enter this directory. Just do not deprive yourself of such a right, otherwise you will have to turn to the superuser! (Note 11)

After reading the previous paragraph, it might seem that read directory access does not provide anything new compared to execute access. However, there is still a difference in these rights. If you set only execute permission, you can enter the directory, but you will not see a single file there (this effect is especially evident if you use some kind of file manager, for example, the Midnight Commander program). If you have access rights to any of the subdirectories of this directory, then you can go to it (with the command cd), but, as they say, "blindly", from memory, because you will not see a list of files and subdirectories of the current directory.

The algorithm for checking user rights when accessing a file can be described as follows. The system first checks if the username matches the file owner's name. If these names match (i.e., the owner accesses his file), then it is checked whether the owner has the appropriate access right: read, write, or execute (do not be surprised, the superuser can deprive the owner of the file of some rights too). If there is such a right, then the corresponding operation is allowed. If the owner does not have the necessary right, then the check of the rights granted through the group or through the group of access attributes for other users is not even checked, and the user is given a message that the requested action cannot be performed (usually something like "Permission denied").

If the name of the user accessing the file does not match the name of the owner, then the system checks whether the owner belongs to the group that is associated with the given file (hereinafter, we will simply call it the group of the file). If owned, then the group-specific attributes are used to determine whether the file can be accessed, and the attributes for the owner and all other users are ignored. If the user is not the owner of the file and is not included in the group of the file, then his rights are determined by the attributes for other users. Thus, the third group of attributes that define file access rights applies to all users except the owner of the file and users included in the group of the file.

To change file permissions, use the command chmod. It can be used in two versions. In the first option, you must explicitly indicate to whom what right you give or whom you deprive of this right:

$ chmod wXp filename

where instead of the symbol w substituted

    or symbol u(i.e. the user who is the owner);

    or g(Group);

    or o(all users not included in the group that owns the file);

    or a(all users of the system, i.e. the owner, the group, and everyone else).

Instead of X put:

    or + (we grant the right);

    or - (we deprive the corresponding right);

    or = (set the specified rights instead of the existing ones),

Instead of p- a symbol denoting the corresponding right:

    r(reading);

    w(record);

    x(performance).

Here are some examples of using the command chmod:

$ chmod a+x file_name

grants all system users the right to execute this file.

$ chmod go-rw file_name

removes read and write permission for everyone except the owner of the file.

$ chmod ugo+rwx file_name

gives everyone read, write, and execute permissions.

If we omit the indication of who is granted this right, then it is understood that we are talking about all users in general, i.e. instead of $ chmod a+x file_name

can be written simply

$ chmod +x file_name

The second command option chmod(it is used more often) is based on a digital representation of the rights. To do this, we encode the character r with the number 4, the character w with the number 2, and the character x with the number 1. In order to grant users some set of rights, we must add the corresponding numbers. Having thus obtained the necessary numeric values ​​for the file owner, for the file group and for all other users, we set these three digits as an argument to the command chmod(we put these numbers after the command name before the second argument, which specifies the file name). For example, if you need to give all rights to the owner (4+2+1=7), the right to read and write to the group (4+2=6), and not give any rights to the rest, then you should issue the following command:

$ chmod 760 file_name

If you are familiar with the binary encoding of octal digits, then you will understand that the numbers after the command name in this form of its representation are nothing more than the octal notation of the same 9 bits that set the rights for the file owner, file group and for all users.

Change file permissions using the command chmod only the owner of the file or the superuser can. In order to be able to change the group's permissions, the owner must additionally be a member of the group to which he wants to grant permissions to the file.

To complete the story about file permissions, we need to talk about three more possible file attributes that are set using the same command chmod. These are the same attributes for executable files that occupy positions 5-7 in the file inode in the two-byte structure that defines the rights to the file, immediately after the file type code.

The first of these attributes is the so-called "user ID change bit". The meaning of this bit is as follows.

Usually, when a user starts a program for execution, that program gets the same file and directory permissions that the user who started the program has. If the "change user ID bit" is set, then the program will have access rights to files and directories that the owner of the program file has (thus, the attribute in question is better called the "change owner ID bit"). This allows you to solve some tasks that would otherwise be difficult to perform. The most typical example is the command to change the password passwd. All user passwords are stored in the /etc/passwd file, which is owned by the superuser root. Therefore, programs launched by ordinary users, including the command passwd, cannot write to this file. And, therefore, the user, as it were, cannot change his own password. But the /usr/bin/passwd file has the "owner ID change bit" set, which is the user root. Therefore, the password changer passwd run with rights root and gains write access to the /etc/passwd file (it is already ensured by the program itself that the user can change only one line in this file).

The "ownership bit" can be set by the superuser with the command

# chmod +s file_name

The "group ID change bit" works in a similar way.

Another possible attribute of an executable file is the "task save bit" or "sticky bit" (literally - "sticky bit"). This bit tells the system to save the program to RAM after the program has finished. It is convenient to turn this bit on for tasks that are frequently called for execution, since in this case time is saved on loading the program at each new start. This attribute was required on older computers. It is rarely used on modern high-speed systems.

If you use the numeric option for setting attributes in the command chmod, then the numeric value of these attributes must precede the digits that specify the user's rights:

# chmod 4775 filename

In this case, the weights of these bits to obtain the desired total result are given as follows:

    4 - "user ID change bit",

    2 - "group ID change bit",

    1 - "task save bit (sticky bit)".

If any of these three bits are set to 1, then the output of the command changes slightly. ls-l in terms of displaying the set access rights attributes. If the "change user ID bit" is set to 1, then the character "x" in the file owner group is replaced by the character "s". Moreover, if the owner has the right to execute the file, then the symbol "x" is replaced by a small "s", and if the owner does not have the right to execute the file (for example, the file is not executable at all), then "S" is put instead of "x". Similar substitutions take place when the "group ID change bit" is set, but the character "x" in the group of attributes that specify group rights is replaced. If the "sticky bit" is 1, then the character "x" in the attribute group that defines the rights for all other users is replaced, with "x" being replaced by the character "t" if all users can run the file for execution, and symbol "T" if they do not have such a right.

Thus, although in the output of the command ls-l there are no separate positions for displaying the values ​​of the identifier change bits and the task save bit, the corresponding information is displayed. Here is a small example of what it would look like:

# ls -l prim1

V. Kostromin (kos at rus-linux dot net) - 4.5. Permissions for files and directories

Now let's talk a little about the differentiation of access rights to various elements. The mechanism described in this article is fundamental in Linux and, accordingly, in Ubuntu, so read carefully.

Users and groups

Linux in general and Ubuntu in particular are multi-user systems, i.e. There can be several different users on the same computer, each with their own settings, data, and access rights to various system functions.

In addition to users in Linux, there are groups to differentiate rights. Each group, like a separate user, has a certain set of access rights to various components of the system, and each user member of this group automatically receives all the rights of the group. That is, groups are needed to group users according to the principle of the same authority for any action, such a tautology. Each user can be a member of an unlimited number of groups, and each group can have as many users as desired.

For example, Ubuntu has one very useful group: admin . Any member of this group receives unlimited administrative privileges. I already talked about the administrator role in Ubuntu, so if you have already forgotten who it is, you can brush up on your knowledge. Created at installing Ubuntu the user automatically becomes a member of the admin group.

You can manage users and groups using a special tool located in the menu System→Administration→Users and groups.

In general, the main area of ​​\u200b\u200bapplication of the user and group mechanism is not exactly access control to various system functions, but rather access control to files on the hard drive. This is what I will try to tell further.

Permissions in Linux

Every file and directory in Linux has an owner user and an owner group. That is, any file and directory belongs to some system user and some group. In addition, any file and directory has three permission groups: one for the owner user, one for members of the owner group, and one for all other system users. Each group consists of the rights to read, write and run the file for execution. For directories, execute permission and read permission always go together and mean the same thing.

That is, by changing the owners of a particular file and various groups of access rights to it, you can flexibly control access to this file. For example, by making yourself the owner of a file and completely denying access to it to anyone except the owner user, you can hide the contents and prevent all other users from modifying this file. The same thing happens with directories. You can, for example, prohibit writing files to a directory, or even hide its contents from prying eyes.

AT this moment we are interested in one extremely important consequence of such an organization of access rights in the system. A particular Ubuntu user owns only his home directory and all of its contents. On the system, this directory is located at /home/username. All other files on the system, including all applications, system settings, etc. located outside of /home , are predominantly owned by root . Remember, I said that root is a user with unlimited privileges, whose direct use is prohibited in Ubuntu. So, all system files and directories belong to root for good reason, they all have the rights to change only for the owner user, so no one except root can interfere with the system and change something in the system files.

This is of course very good for security, but what if you need to change some system files? There are two ways: firstly, most of the user needs system settings can be changed with administrator rights from the graphical configurators, this is the preferred way. Well, secondly, you can temporarily increase your rights to root and do whatever you want.

This is done using the sudo utility and its derivatives. sudo is a console utility. It allows you to "pretend" as a root when executing a specific command, thus gaining unlimited rights. For example, the command

sudo aptitude update

will update the data about the applications available to you (I will explain why this is necessary in the article about program management). The team itself

Aptitude update

only works if root runs it. However, by running it with sudo you are pretending to be root without actually being root. Naturally, you must have administrator rights to use sudo. At the same time, when you run the command through sudo, the system will ask you for your password, however, for security reasons, when you enter it, nothing will be shown to you, no asterisks, no dashes, no birds, nothing. Don't be scared, that's the way it should be, just enter to the end and press Enter. If you are an administrator and entered the correct password, then the command specified after sudo will be executed as root .

You can do anything through the terminal, so having the option to become root you can do all the settings you need. However, sometimes it is convenient to use graphical applications, while having root rights. For example, if you need to copy files to system directories. To run graphical applications as root, open the GNOME run dialog with Alt + F2 and type

gksudo appname

For example, to launch the Nautlus file manager, type

gksudo nautilus

Through Nautilus launched in this way, you can modify any files on the computer as you like.

Be extremely careful when using Nautilus with as root! You can permanently delete any system file without any warnings, which can easily lead to the inoperability of the entire system.

Editing configuration files

The most important example of the application of the above technology of "estimating" the root is editing the configuration files of the system. I already said that all system settings and all applications in Linux are stored in the form text files. So, you can only edit files that belong to you, that is, only settings related to your user. And to edit system settings, you will need administrator rights.

You will be able to open many files, but you will not be able to change anything in them, the save operation will simply not be available to you:

Of course, you can open configuration files as root through the application launcher with the command

Gksudo gedit /path/to/file

Gedit is Ubuntu's standard text editor.

However, auto-completion does not work in the launch dialog, so you will have to type the path to the file manually, which is not always convenient. Therefore, you can use the terminal to run the text editor as the superuser, for example:

Note that sudo is a purely console utility, so you cannot use it in the application launcher, although you can run graphical applications from the terminal through it. And gksudo, on the contrary, is a graphical utility, so it should not be used in the terminal, although this is not prohibited.

As a result, the editor will open with the ability to save changes.

In this tutorial, we'll look at how to delete a Linux user along with their data and home directory.

If you are a system administrator in a large company, then most likely, deleting linux users is a fairly common task for you. Once an account is no longer needed or a user leaves the organization, the account must be deleted to avoid leaving security holes.

When deleting Linux users, it is also important to delete their home directory to free up storage space for the new users and their files. First, we will look at how to delete a Linux user using the terminal, then we will talk about how this is done in the graphical interface of one of the most popular distributions - Ubuntu.

Before moving on to the real world, let's do some practice, let's create two users, losst and losst1, along with their home directories, and then delete them:

adduser losst
$passwd losst

adduser losst1
$ passwd losst1

Here the adduser command is used to create a user account and passwd to create a password.

Let's take a look at how to delete a Linux user in the terminal. This is done using the -deluser command on debian and derived systems, and on RedHat - userdel. Let's take a closer look at these two utilities.

Description of deluser

The syntax of the deluser command is very simple:

$ deluser parameters user

The deluser command settings are located in the /etc/deluser.conf file, among other settings, it specifies what to do with the user's home folder and files.

You can view and change these settings by running the command:

vi /etc/deluser.conf

Let's take a closer look at these settings:

  • REMOVE_HOME- delete the user's home directory
  • REMOVE_ALL_FILES- delete all user files
  • BACKUP- fulfill backup user files
  • BACKUP_TO- backup folder
  • ONLY_IF_EMPTY- delete user group if it is empty.

These settings determine the default behavior of the utility when a user is deleted, of course, they can be overridden using parameters for the command.

The following parameters are supported, they are similar to the settings, but there are more options:

  • --system- delete only if this is a system user
  • --backup- do backup user files
  • --backup-to- backup folder
  • --remove-home- delete home folder
  • --remove-all-files- delete all user files in the file system

Description of userdel

The userdel utility works a little differently, there is no settings file here, but there are options that you can use to tell the utility what to do. The syntax is similar:

$ userdel parameters user

  • -f, --force- forced deletion even if the user is still logged in
  • -r, --remove- delete the user's home directory and his files in the system.
  • -Z- delete all SELinux objects for this user.

To remove a user from the server, it is better to use the advanced method, which we will discuss below. When users use the server, they run various programs and services. The user can only be properly deleted if he is not logged in on the server and all programs running on his behalf are stopped, because programs can use various files owned by the user, which prevents them from being deleted. Accordingly, then the user's files will not be completely deleted and will remain clog the system.

User account lockout

You can use the passwd utility to lock out a user account. This will deny the user access to the system and prevent new processes from starting:

Run the passwd command with the --lock option:

passwd --lock loss

passwd: Password expiration information changed.

Kill all running user processes

Now let's find all the processes running as user and kill them.

Find processes with pgrep:

You can see in more detail what these processes are by passing the pid of each of them to the ps command, like this:

ps -f --pid $(pgrep -u losst)

UID PID PPID C STIME TTY STAT TIME CMD
losst 14684 14676 0 22:15 pts/2 S 0:00 -bash
losst 14735 14684 0 22:15 pts/2 S+ 0:00 vi text

Now that you've made sure there's nothing important in there, you can kill all processes with the killall command:

Killall -9 -u loss

The -9 option tells the program to send a SIGKILL to these processes, and -u specifies the username.

On Red Hat based systems, to use killall you will need to install the psmisc package:

sudo yum install psmisc

Backing up user data

This is not necessary at all, but for a serious project it would not be superfluous to back up the user's files, especially if there could be important files there. To do this, you can use, for example, the tar utility:

tar jcvf /user-backups/losst-backup.tar.bz2 /home/losst

Deleting a user account

Now that everything is ready, let's start deleting the linux user. Just in case, we explicitly indicate that you need to delete the user's files and home directory. For Debian:

deluser --remove-home losst

userdel --remove loss

If you need to remove all files owned by a user on the system, use the --remove-all-files option, just be careful with it, as important files can be overwritten:

deluser --remove-all-files losst

The user is now completely removed, along with their files and home directory, from your system.

Deleting a User in Ubuntu

Open System Settings:

Open item Accounts:

As you can see, now all actions are unavailable, and are drawn in gray. Click the button to activate them. unlock and enter the user's password.

Now, in order to delete a user in linux, just click on it with the mouse, and then click on the minus sign.

In the window that opens, you can choose what to do with the user's files:

Naturally, only the home folder will be deleted, we are not talking about all the files. And for correct removal, the user must not work in the system.

conclusions

Deleting a user in linux is not that difficult, no matter where it needs to be done, on the server or home computer. Of course, the graphical interface is more convenient, but the terminal, as always, offers more options. If you have any other ideas about this, write in the comments!

Similar posts