He could then add himself to the wheel
Using Groups to Avoid Using Root In addition to being a security concern, the root password distribution policy can cause contention in any organization. Many sysadmins hate giving out the root password, even to people who are responsible for maintaining part of the system. If this sort of sysadmin doesn’t know how to properly manage the computer, this reluctance can prevent people from doing their jobs. Many other sysadmins hand out root to dang near anyone who wants it and then complain when the system becomes unstable. Both attitudes are untenable in the long run, especially when UNIX has powerful facilities for removing the need to use the root password. One common situation is where a junior administrator is responsible for a particular portion of the system. I’ve had many DNS administrators work under me; these people don’t ever install software, recompile the kernel, or do other low-level system tasks. They just answer emails, update zone files, and reload named. New junior admins frequently seem to think that they need root access to do this sort of work. By establishing your own groups, consisting of users who perform similar administrative functions, you can let people do their jobs without the root password. In this section, we’ll implement group-level access control over nameserver files. The same principles apply to any files you should choose to protect. (Mail and web configuration files are other popular choices for this sort of delegation.) OpenBSD has reserved user accounts for use by programs integrated with the system. For example, the nameserver runs under the user account called “named” and the group “named.” As we covered earlier, if an intruder compromised the nameserver, she could only access the system with the privileges of the nameserver user. You can create a group called “dns” that includes the people who manage your nameserver. Do not use the program user for this sort of work! While you want programs run by the user named to be able to read files owned by the group “dns,” you do not want the nameserver program to be able to write to files owned by the dns group. This further minimizes the damage a nameserver daemon compromise could inflict. The simplest way to create a group to own files is to create a user to own them, and use that user’s primary group as the group of the files. Adduser(8) will let you create a user to own these files. Because we already have a user “named,” we’ll call this administrative user “dns.” The name isn’t that important, but you should choose a name that you’ll be able to remember easily. # adduser -silent Enter username [a-z0-9_-]: dns Enter full name []: DNS Administration User Enter shell csh ksh nologin sh [csh]: nologin Give your administrative user a shell of “nologin,” which gives the user the shell of /sbin/nologin. Nobody can log in with this account. Uid [1001]: If you want, you could specify a particular uid for these sorts of users. I’ve been known to choose uid numbers close to those used by the users for their related programs. For example, named has a uid of 70. I could decide to give dns a uid of 1,070 to keep some sort of relationship between my private system users and those used by OpenBSD. Remember, user IDs below 1,000 are reserved for OpenBSD’s internal use. Login group dns [dns]: Login group is “dns'’. Invite dns into other groups: guest no [no]: The whole point of this sort of user is that they have their own group. Under no circumstances should you add such an administrative user to another group! Page 148
Hint: This post is supported by Gama besplatan domen provider