{"id":233,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:40","modified_gmt":"2020-08-22T20:26:40","slug":"this-is-the-page-title-toplevel-68","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=233","title":{"rendered":"User Accounts"},"content":{"rendered":"\nUser Accounts<\/title>\n<concept id=\"\" description=\"Users gain access to the sysetm through a 'user account'.\" \/>\n<concept id=\"\" description=\"The user account defines (among other things) the environment in which the user works.\" \/>\n<p>\nUsers gain access to the system only after the system administrator\nhas created <i>user accounts<\/i> for them. These accounts are more than just a\nuser name and password; they also define the <glossary>environment<\/glossary>\nthe user works under, including the level of access he or she has.\n<\/p>\n<concept id=\"\" description=\"Users can be added to the system using the useradd command\" \/>\n<task name=\"\">Add a user to the system<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\n<\/p>\n<p>\nUsers are added to Linux systems in one of two ways. You could create the necessary entries in the\nappropriate files, create the directories, and copy the start-up files manually. This is <em>not<\/em> recommended.\nOr, you could use the <command>useradd<\/command> command, which does that for you. Also,\nthere are many graphical tools to do this for you, depending on what <glossary>distribution<\/glossary> and\n<glossary>desktop environment<\/glossary> you are using.\n<\/p>\n<p>\nFrom the command-line, creating a user is done with the <command>useradd<\/command> command, to add the user daniel, it might look something like this:\n<\/p>\n<ol>\n<li>Login as the root user<\/li>\n<li>Issue the command <commandexample command=\"useradd\">useradd daniel<\/commandexample>\n<\/ol>\n<question id=\"120\" text=\"The terms 'user' and 'user account' are often interchanged in different contexts.\" \/>\n<question id=\"121\" text=\"Typically a 'user' is a real person and the 'user account' is the evironment when the user logs in.\" \/>\n<concept id=\"121\" description=\"The terms 'user' and 'user account' are often interchanged in different contexts.\" \/>\n<concept id=\"122\" description=\" Typically a 'user' is a real person and the 'user account' is the evironment when the user logs in. \" \/>\n<p>\nAdding a user to a Linux system is often referred to as “creating a user” or\n“creating a user <glossary>account<\/glossary>“.\nThe terms “user” and “user account” are often interchanged in different contexts.\nFor the most part, the term “user” is used for the person actually working on the system\nand “user <glossary>account<\/glossary>” is used to refer to the files and programs that\ncreate the user’s <glossary>environment<\/glossary>\nwhen he or she logs in. However, these two phrases\ncan be interchanged and people will know what you are referring to.\n<\/p>\n<p>\nIn this example, we simply created the user based on the previously defined defaults. However, as we will go into later, there are\na number of options you can provide on the command-line.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"Which of the following is typically not something done when a user is added to the system?\" \/>\n<p>\nWhen an <glossary>account<\/glossary> is created, typically a\n<glossary>shell<\/glossary> is assigned along with the default configuration\nfiles that go with that <glossary>shell<\/glossary>. Users are also assigned a\n<glossary>home directory<\/glossary>, which is their default directory when they\n<glossary>login<\/glossary>, usually in the form \/home\/<username>. Note that\nthe parent of the user’s home directories may be different.\n<\/p>\n<concept id=\"\" description=\"It is possible to create a user without setting up things like the shell or home directory.\" \/>\n<question id=\"\" type=\"tf\" text=\"It is possible to create a user without setting up things like the shell or home directory.\" \/>\n<task name=\"\">Create a user with a non-default gome directory<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\n<\/p>\n<p>\nNote that these are actually seperate option to the <command>useradd<\/command> command. It is possible\nto create a user without setting up as one would expect. In many cases, users are created that never login, so, for example, a home directory is not needed or they get a home directory completely different from “normal” users.\nIn this example, we will add a user for the software “MyDB” and specify a non-default home directory.\n<\/p>\n<ol>\n<li>Login as root.<\/li>\n<li>Issue the command <commandexample command=\"useradd\">useradd -d \/opt\/mydb mydb<\/commandexample>\n<\/ol>\n<p>\nAs an alternative to the <glossay>short option<\/glossary> <keyinput>-d<\/keyinput>, you can also use the <glossay>long option<\/glossary> <keyinput>–home<\/keyinput>.\n<\/p>\n<p>\nKeep in mind that this command simply configures the <i>user<\/i> as you have defined. It does <b>not<\/b> create the directory, nor set permissions. This needs to be done manually.\n<\/p>\n<task name=\"\">Create a user and assign it to a specific primary group<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\n<\/p>\n<p>\nWhen user accounts are created, each user is assigned a User\nName (login name or logname), which is associated with a User ID (<glossary>UID<\/glossary>). Each is\nassigned to at least one group, with one group designated as their <i>login\ngroup<\/i>. Each group has an associated Group ID (<glossary>GID<\/glossary>). The <glossary>UID<\/glossary>\nis a number used to identify the user. The <glossary>GID<\/glossary>\nis a number used to identify the <glossary>login<\/glossary> group of\nthat user. Both are used to keep track of that user and determine what files he\nor she can access.\n<\/p>\n<ol>\n<li>Login as root.<\/li>\n<li>Issue the command <commandexample command=\"useradd\">useradd -g backup david<\/commandexample><\/li>\n<li>Check that both the \/etc\/passwd and \/etc\/group files were updated correctly.<\/li>\n<\/ol>\n<concept id=\"\" description=\"When a user account is created it is assigned a username and a UserID.\" \/>\n<p>\n<p>\nNote that here too it would be possible to create a user that did not belong to any group. However,\nthat is an exception and I have never seen in done in practice.\n<\/p>\n<task name=\"\"> Understand the contents of the \/etc\/passwd file.<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\n<\/p>\n<ol>\n<li>Issue the command <commandexample>cat \/etc\/passwd<\/commandexample><\/li>\n<li>The output for one of the lines might look like this:\n<p>\n<screenoutput>\njimmo:x:1000:100::\/data\/home\/jimmo:\/bin\/bash\n<\/screenoutput>\n<\/p>\n<\/ol>\n<p>\nThe fields in the <file>\/etc\/passwd<\/file> file are:\n<\/p>\n<ul>\n<li>username<\/li>\n<li>encrypted password on older systems, “x” on newer systems that use shadow passwords<\/li>\n<li>User ID<\/li>\n<li>Group ID<\/li>\n<li>GECOS field, typically contains the users’ fullname, but often other informaiton like department or telephone number. <\/li>\n<li>Home directory<\/li>\n<li>Login shell<\/li>\n<concept id=\"\" description=\"The group which a user is a part of is only typically only used for determining access to files.\" \/>\n<concept id=\"\" description=\"Most identification of users is done through the UID and GID.\" \/>\n<question id=\"\" type=\"tf\" text=\"Most identification of users is done through the UID and GID.\" \/>\n<question id=\"\" type=\"tf\" text=\"A user can only belong to a single group and muist switch groups to gain more access.\" \/>\n<p>\nIn general, programs and commands that interact with\nus humans report information about the user by <glossary>logname<\/glossary>\nor group name. However,\nmost identification from the operating system’s point of view is done through the\n<glossary>UID<\/glossary> and\n<glossary>GID<\/glossary>. The UID is associated with the user’s\n<glossary>logname<\/glossary>. The GID is associated\nwith the user’s <glossary>login<\/glossary> group. In general, the group which a user is a part of\nis only typically only used for determining access to files.\n<\/p>\n<concept id=\"\" description=\"User accounts are defined in the \/etc\/passwd file.\" \/>\n<concept id=\"\" description=\"User groups are defined in the \/etc\/group file.\" \/>\n<question id=\"\" type=\"\" text=\"User accounts are defined in the \/etc\/shadow file.\" \/>\n<concept id=\"\" description=\"Users can typically read the contents of both the \/etc\/passwd and \/etc\/group files.\" \/>\n<question id=\"\" type=\"TF\" text=\"For security reasons, normal users are not allowed to read the \/etc\/passwd file.\" \/>\n<p>\nUser accounts are defined in <file type=\"\">\/etc\/passwd<\/file> and groups are\ndefined in <file type=\"\">\/etc\/group<\/file>. If you look on your system, you will\nsee that everyone can read both of these files. Years ago, my first reaction was\nthat this was a <glossary>security<\/glossary>\nproblem, but when I was told what this was all about, I\nrealized that this was necessary. I was also concerned that the password be\naccessible, even in encrypted format. Because I know what my password is, I can\ncompare my password to the encrypted version and figure out the encryption\nmechanism, right? Nope! Its not that easy.\n<\/p>\n<p>\nAt the beginning of each\nencrypted password is a <i>seed<\/i>. Using this seed, the system creates the\nencrypted version. When you <glossary>login<\/glossary>, the system takes the seed from the encrypted\npassword and encrypts the password that you input. If this matches the encrypted\npassword, you are allowed in. <b>Nowhere<\/b> on the system is the\n<b>unencrypted<\/b> password stored, nor do any of the utilities or commands generate it. Note this\nencryption method is now common knowledge, so storing the password like this is not a good idea as we’ll get to shortly.\n<\/p>\n<question id=\"124\" text=\"The name of the file's owner is not stored in the file's inode.\" \/>\n<concept id=\"123\" description=\"The name of the file's owner is not stored in the file's inode.\" \/>\n<p>\nNext, lets talk about the need to be able to access this information.\nRemember that the <glossary>operating system<\/glossary>\nknows only about numbers. When we talked\nabout <glossary>operating system<\/glossary>\nbasics, I mentioned that the information about the owner\nand group of a file was stored as a number in the <glossary>inode<\/glossary>.\nHowever, when you do a long listing of a file (ls -l), you don’t see the number, but rather, a name.\nFor example, if we do a long listing of <file type=\"\">\/bin\/<command>mkdir<\/command><\/file>, we get:<\/p>\n<p>\n<screenoutput>-rwxr-xr-x 1 root root 7593 Feb 25 1996 \/bin\/mkdir<\/screenoutput>\n<\/p>\n<p>\nThe entries are:\n<\/p>\n<p>permissions links owner group size date filename<\/p>\n<question id=\"122\" text=\"What file makes the translation between a user's name and their user ID (UID)?\" \/>\n<p>\nHere we see that the owner and group of the file is root. Because the owner and group are\nstored as numerical values in the <glossary>inode<\/glossary>\ntable, the system <em>must<\/em> be\ntranslating this information before it displays it on the screen. Where does it\nget the translation? From the <file type=\"\">\/etc\/passwd<\/file> and\n<file type=\"\">\/etc\/group <\/file>files. You can see what\nthe “untranslated” values are by entering\n<p>\n<commandexample command=\"ls\">ls -ln \/bin\/mkdir<\/commandexample>\n<\/p>\nwhich gives us:<\/p>\n<p>\n<screenoutput>-rwxr-xr-x 1 0 0 7593 Feb 25 1996 \/bin\/mkdir<\/screenoutput>\n<\/p>\n<p>\nIf we look in <file type=\"\">\/etc\/passwd<\/file>, we see that the 0 is the <glossary>UID<\/glossary>\nfor root, and if we look in <file type=\"\">\/etc\/group<\/file>, we see that 0 is also the <glossary>GID<\/glossary> for the group\nroot, which are the numbers we got above. If the <file type=\"\">\/etc\/passwd<\/file>\nand <file type=\"\">\/etc\/group<\/file>\nfiles were not readable by everyone, then no translation could be made like this\nwithout some major changes to most of the system commands and utilities.\n<\/p>\n<p>\nOn a number of occasions, I have talked to people who claimed to have\nexperienced corruption when transferring files from one system to another.\nSometimes it’s with <command>cpio<\/command>, sometimes it’s <command>tar<\/command>. In every case, files have arrived on\nthe destination machine and have had either “incorrect” owners or\ngroups and sometimes both. Sometimes, the “corruption” is so bad that\nthere are no names for the owner and group, just numbers.\n<\/p>\n<p>\nNumbers, you say? Isn’t that how the system stores the owner and group information for the\nfiles? Exactly. What does it use to make the translation from these numbers to\nthe names that we normally see? As I mentioned, it uses <file type=\"\">\/etc\/passwd<\/file> and\n<file type=\"\">\/etc\/group<\/file>. When you transfer files from one system to another, the only owner\ninformation that is transferred are the numbers. When the file arrives on the\ndestination machine, weird things can happen. Lets look at an example.<\/p>\n<p>\nAt work, my <glossary>user name<\/glossary> was jimmo and I had\n<glossary>UID<\/glossary> 12709. All my files were stored with\n12709 in the owner field of the <glossary>inode<\/glossary>.\nLet’s say that I create a user on my machine at home, also named jimmo. Because there are far fewer users on my system at home than at work, jimmo ended up with <glossary>UID<\/glossary>\n500. When I transferred\nfiles from work to home, the owner of all “my” files was 12709. That\nis, where there normally is a name when I do a long listing, there was the\nnumber 12709, not jimmo. <\/p>\n<p>\nThe reason for this is that the owner of the\nfile is stored as a number in the <glossary>inode<\/glossary>.\n When I copied the files from my system\nat work, certain information from the <glossary>inode<\/glossary>\nwas copied along with the file,\nincluding the owner. <i>Not<\/i> the user’s name, but the numerical value in the\ninode. When the files were listed on the new system, there was no user with <glossary>UID<\/glossary>\n12709, and therefore no translation could be made from the number to the name.\nThe only thing that could be done was to display the number.<\/p>\n<p>\nThis makes\nsense because what if there were no user jimmo on the other system? What value\nshould be displayed in this field? At least this way there is some value and you\nhave a small clue as to what is going on.\n<\/p>\n<p>\nTo keep things straight, I had\nto do one of two things. Either I create a shell script that changed the owner\non all my files when I transferred them or I figure out some way to give jimmo\n<glossary>UID<\/glossary> 12709 on my system at home. So I decided to give jimmo UID\n12709.\n<\/p>\n<p>\nHere, too, there are two ways I can go about it. I could create\n12208 users on my system so the 12709th would be jimmo. (Why 12208? By default,\nthe system starts with a <glossary>UID<\/glossary>\n500 for normal users.) This bothered me though,\nbecause I would have to remove the user jimmo with <glossary>UID<\/glossary>\n500 then create it again.\nI felt that this would be a waste of time.\n<\/p>\n<concept id=\"\" description=\"You can change a user's login name or even ID if necessary.\" \/>\n<question id=\"123\" text=\"Once a user a user is created there is no way to change the user ID (UID).\" \/>\n<p>\nThe other alternative was to\nchange the system files. Now, there is nothing that Linux provides that would do\nthat. I could change many aspects of the user jimmo; however, the <glossary>UID<\/glossary>\nwas not\none of them. After careful consideration, I realized that there was a tool that\nLinux provided to make the changes: <command>vi<\/command>. Because this information is kept in\nsimple text files, you can use a text editor to change them. After reading the\nremainder of this chapter, you should have the necessary information to make the\nchange yourself.<\/p>\n<p>\nOne thing I would like to point out is that <command>vi<\/command> is not\nactually the tool you should use. Although you could use it, something could\nhappen while you are editing the file and your password file could get trashed.\nLinux provides you with a tool (that’s actually available on many systems)\nspecifically designed to edit the password file: <command>vipw<\/command> (for “vi\npassword”).\n<\/p>\n<p>\nWhat <command>vipw<\/command> does is create a copy of the password file,\nwhich is what you actually edit. When you are finished editing, vipw replaces\nthe \/etc\/passwd with that copy. Should the system go down while you are editing\nthe file, the potential for problems is minimized. Note that despite its name,\nthe editor that is called is defined by your <site id=\"18\">EDITOR environment variable<\/site>.\nThe <command>vipw<\/command> can be used to not only edit the <file type=\"\">passwd<\/file> file, but also the <file type=\"\">group<\/file> or <file type=\"\">shadow<\/file> file, as well.\n<\/p>\n<p>\nWhen the first customer called with the same situation, I could\nimmediately tell him why it was happening, how to correct it, and assure him\nthat it worked.\n<\/p>\n<concept id=\"\" description=\"You can change a user's group if necessary.\" \/>\n<question id=\"\" type=\"tf\" text=\"once set you cannot change a user's primary group.\" \/>\n<p>\nYou can also change a user’s group if you want. Remember,\nhowever, that all this does is change the <glossary>GID<\/glossary>\nfor that user in <file type=\"\">\/etc\/passwd<\/file>.\nNothing else! Therefore, all files that were created before you make the change\nwill still have the old group.\n<\/p>\n<concept id=\"65\" description=\"You can switch the user you run a program as using the 'su' command.\" \/>\n<question id=\"125\" text=\"What command would you use to switch your user ID before running a command?\" \/>\n<p>\nYou can change your <glossary>UID<\/glossary>\nwhile you are\nworking by using the <command>su<\/command> command. What does su stand for? Well, that’s a good\nquestion. I have seen several different translations in books and from people on\nthe Internet. I say that it means “switch <glossary>UID<\/glossary>“, as that’s what it does.\nHowever, other possibilities include “switch user” and\n“super-user.” This command sets your <glossary>UID<\/glossary>\nto a new one. The syntax is<\/p>\n<p>\n<commandexample command=\"su\">su <user_name><\/commandexample>\n<\/p>\n<p>\nwhere <user_name> is the <glossary>logname<\/glossary> of\nthe user whose <glossary>UID<\/glossary>\nyou want to use. After running the command, you have a UID of\nthat user.\n<\/p>\n<p>\nThe shortcoming with this is that all that is changed is the\nUID and GID; you still have the <glossary>environment<\/glossary>\nof the original user. If you want\nthe system to “pretend” as though you had actually logged in, include\na dash (-). The command would then be<\/p>\n<p>\n<commandexample command=\"su\">su – <user_name><\/commandexample>\n<\/p>\n<p>\nWhat is\nactually happening is that you are running a new <glossary>shell<\/glossary>\nas that user. (Check the\n<command>ps<\/command> output to see that this is a new process.) Therefore, to switch back, you\ndon’t need to use su again, but just exit that <glossary>shell<\/glossary>.\n<\/p>\n<p>\nWe need to remember that a <glossary>shell<\/glossary>\nis the primary means by which users gain access to the system. Once\nthey do gain access, their ability to move around the system (in terms of\nreading files or executing programs) depends on two things: <glossary>permissions<\/glossary>\nand privileges.\n<\/p>\n<concept id=\"\" description=\"In general, there is no need to switch groups.\" \/>\n<p>\nIn general, there is no need to switch groups. A user can be\nlisted in more than one group in <file type=\"\">\/etc\/group<\/file> and the system will grant access to\nfiles and directories accordingly.\n<\/p>\n<p>\nPermissions are something that most people are familiar with if they have ever worked on an Linux (or similar)\nsystem before. Based on what has been granted, different users have different\naccess to files, programs, and directories. You can find out what <glossary>permissions<\/glossary>\na particular file has by doing a long listing of it. The <glossary>permissions<\/glossary>\nare represented by the first 10 characters on the line. This is something that we\ncovered in a fair bit of detail in the section on <glossary>shell<\/glossary>\nbasics, so there is no need to repeat it here.\n<\/p>\n<p>\nRemoving users is fairly straightforward.\nUnfortunately, I haven’t found a utility that will remove them as simply as you\ncan create them. Therefore, you will need to do it manually. The simplest way is\nto use <command>vipw<\/command> to remove the users entry from <file>\/etc\/passwd<\/file> and to remove its home directory and mailbox.\n<\/p>\n<p>\nHowever, this is not necessarily the best\napproach. I have worked in companies where once a user was created, it was never\nremoved. This provides a certain level of accountability.\n<\/p>\n<p>\nRemember that the owner is simply a number in the <glossary>inode<\/glossary>\ntable. Converting this number to a name is done through the entry in <file type=\"\">\/etc\/passwd<\/file>. If that entry\nis gone, there can be no conversion. If a new user were to get the <glossary>UID<\/glossary>\nof an old, removed user, it may suddenly have access to a file that it shouldn’t (i.e., a file owned by the\nold user that it now owns).\n<\/p>\n<p>\nEven if no new users get that <glossary>UID<\/glossary>, what do\nyou do if you find an “unowned” file on your system, that is, one with\njust a number as the owner and without associated entry in <file type=\"\">\/etc\/passwd<\/file>? What you\ndo is up to your company, but I think it is safer to “retire” that\nuser.<\/p>\n<concept id=\"\" description=\"To prevent a user from ever logging in, you can change the password to something that cannot be decrypted.\" \/>\n<concept id=\"\" description=\"To prevent a user from ever logging in, you can change their shell entry in \/etc\/passwd to \/bin\/true.\" \/>\n<question id=\"\" type=\"MC\" text=\"Which binary could you use to as a user's shell entry in \/etc\/passwd to prevent them from logging in?\" \/>\n<p>\nYou could remove its <glossary>home directory<\/glossary>\nand mailbox. However, change its\npassword to something like NOLOGIN. This password is shorter than an encrypted\npassword, so it is <i>impossible<\/i> that any input password will <glossary>encrypt<\/glossary>\nto\nthis. Then change its <glossary>login<\/glossary>\n<glossary>shell<\/glossary>\nto something like <command>\/bin\/true<\/command>. This closes one\nmore door. By making it \/bin\/true, no <glossary>error message<\/glossary>\nwill be generated to give a\npotential hacker a clue that there is “something” about this <glossary>account<\/glossary>.\nAlternatively, you could replace the <glossary>login<\/glossary>\n<glossary>shell<\/glossary>\nwith a message to say that the\naccount has been disabled and the owner should report to have it re-activated.\nThis helps to dissuade would-be hackers.\n<\/p>\n<question id=\"427\" text=\"An unencrypted copy of your password is stored in the \/etc\/shadow file.\" \/>\n<question id=\"\" type=\"TF\" text=\"For security reasons, normal users are not allowed to read the \/etc\/shadow file.\" \/>\n<concept id=\"\" description=\"For security reasons, normal users are not allowed to read the \/etc\/shadow file.\" \/>\n<p>\nAnother useful tool for thwarting hackers is password shadowing. With this, the\n<glossary>encrypted password<\/glossary> is\nnot kept in <file type=\"\">\/etc\/passwd<\/file>, but rather <file type=\"\">\/etc\/shadow<\/file>. This is useful when someone decides to steal your password file.\nWhy is this a problem? I will get into details about it later, but lets say now that the password file could be used to\ncrack passwords and gain access to the system.\n<\/p>\n<p>\nBecause you must have the\n<file type=\"\">\/etc\/passwd<\/file> file word-readable to make translations from <glossary>UID<\/glossary>\nto <glossary>user name<\/glossary>,\nyou cannot protect it simply by changing the permission. However, the\n<file type=\"\">\/etc\/shadow<\/file>\npassword, where the real password is stored, is <b>not<\/b> readable by regular users\nand therefore is less of a <glossary>security<\/glossary>\nrisk. (I say “less” because if an intruder gets in as root, all bets are off). <\/p>\n<p>\nWhen\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>User Accounts Users gain access to the system only after the system administrator has created user accounts for them. These accounts are more than just a user name and password; they also define the environment the user works under, including … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=233\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-233","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=233"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/233\/revisions"}],"predecessor-version":[{"id":774,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/233\/revisions\/774"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}