|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
/ home / Authentication
| Groups administration | Recommended Links | Sudo | |||||
| Suse Security | Solaris 10 (RBAC) | SecurID |
Humor |
Etc |
|
|
BSD Unix invented wheel group as a special system group for users who can assume the role of root (switch to root using su or sudo). AIX has similar notion of sugroups. Solaris has sysadmin group (group 14) that is allowed to change permissions of files that user does no own. Generally Solaris 10 RBAC permits much flexible arrangement then wheel group and can be considered as a generalization of this concept.
|
|
Two PAM modules pam_require and pam_wheel can provide functionally for establishing the role of wheel group similar to BSD. It can include ability to su to root without authentication without using sudo.
Ssh usually made exempt from SecurID, but telnet, ftp and r-services (if they are installed) can benefit form being able to limit the userspace for this protocol.
Similar role can be played by several other linux PAM modules, for example pam_listfile ( authenticate users based on the contents of a specified file or ) but this is less elegant as you need to create and maintain the list, which duplicates wheel group. At the same time it is very valuable for control of certain protocols, like ftp.
Examples below are based on Suse 10. Please note that this module is not used by default in SLEC but is available in OpenSuse 10.2 and can copied to SLES.
In Linux it is usually located at /lib/security/pam_wheel.so or /lib64/security/pam_wheel.so
The PAM file that needs to be modified is /etc/pam.d/su
#%PAM-1.0 auth sufficient pam_rootok.so auth required pam_wheel.so auth include common-auth account include common-account password include common-password session include common-session session optional pam_xauth.so
For example:
#%PAM-1.0 auth sufficient pam_rootok.so auth required pam_wheel.so root_only auth include common-auth account include common-account password include common-password session include common-session session optional pam_xauth.so
Notes:
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
03- Let only users set on /etc/security/access.conf be able to login (assuming they already passed the above stacked rules).
In /etc/security/access.conf:
# Accept `root' and `ahmed' logins only (till the system go mainstream)
+:root:ALL
+:ahmed:ALL
-:ALL:ALL
In /etc/pam.d/common-account:
account required pam_access.so
|
|
|
Under RH 6.2 (pam 0.72) I was able to set up su such that only users in the wheel group were able to su to root, but anyone could su to other unprivledged accounts. Now on my 7.1 (pam 0.75) box, if I enable pam_wheel in su, it prevents everyone from using su unless they are in the wheel group instead of just allowing su to root by wheel group
members. Here is my su config for the 7.1 box:#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel"
group.
#auth sufficient /lib/security/pam_wheel.so trust use_uid debug
# Uncomment the following line to require a user to be in the "wheel"
group.
auth required /lib/security/pam_wheel.so use_uid debug
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_xauth.soAnd here is the config from my 6.2 box where it works as I want it to:
#%PAM-1.0
# The next two lines require a user to be in group "wheel" in order to
su to root.
auth sufficient /lib/security/pam_rootok.so debug
auth required /lib/security/pam_wheel.so group=wheel
auth required /lib/security/pam_pwdb.so shadow nullok
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so shadow use_authtok
nullok
session required /lib/security/pam_pwdb.so
session optional /lib/security/pam_xauth.soMy question is, how do I get the same funtionality under 7.1?
TIA,
Matt
|
|
|
From michael.rees on Wed, 07 Jun 2000
Hi, Sorry to bother you but could you help me with the following??
i am running red hat linux 6.1 and am encountering some problems i can login as root from the console but not from anywhere else
i have to login as webmaster on all other machines on ntwk
from nowhere, including the console, can i su once logged in as webmaster
any help would be appreciated
Regards, Michael
Your system is enforcing a very reasonable policy by preventing direct 'root' logins from over the network.The best way to circumvent this policy is to use one of the implementations of SSH (the original SSH by Tatu Ylonen, now owned and commmercially available from DataFellows Inc http://www.datafellows.com, or OpenSSH http://www.openssh.com --- which is ironically at a .com rather than a .org domain, or the GPL'd lsh at http://www.net.lut.ac.uk/psst).
Any of these should allow you to access your system through cryptographically secured authentication and session protocols that protect you from a variety of sniffing, spoofing, TCP hijacking and other vulnerabilties that are common using other forms of remote shell access (such as telnet, and the infamous rsh and rlogin packages).
If you really insist on eliminating these policies from your system you can edit files under /etc/pam.d that are used to configure the options and restrictions of the programs that are compiled against the PAM (pluggable authentication modules) model and libraries. Here's an example of one of them (/etc/pam.d/login which is used by the in.telnetd service):
# # The PAM configuration file for the Shadow `login' service # # NOTE: If you use a session module (such as kerberos or NIS+) # that retains persistent credentials (like key caches, etc), you # need to enable the `CLOSE_SESSIONS' option in /etc/login.defs # in order for login to stay around until after logout to call # pam_close_session() and cleanup. # # Outputs an issue file prior to each login prompt (Replaces the # ISSUE_FILE option from login.defs). Uncomment for use # auth required pam_issue.so issue=/etc/issue # Disallows root logins except on tty's listed in /etc/securetty # (Replaces the `CONSOLE' setting from login.defs) auth requisite pam_securetty.so # Disallows other than root logins when /etc/nologin exists # (Replaces the `NOLOGINS_FILE' option from login.defs) auth required pam_nologin.so # This module parses /etc/environment (the standard for setting # environ vars) and also allows you to use an extended config # file /etc/security/pam_env.conf. # (Replaces the `ENVIRON_FILE' setting from login.defs) auth required pam_env.so # Standard Un*x authentication. The "nullok" line allows passwordless # accounts. auth required pam_unix.so nullok # This allows certain extra groups to be granted to a user # based on things like time of day, tty, service, and user. # Please uncomment and edit /etc/security/group.conf if you # wish to use this. # (Replaces the `CONSOLE_GROUPS' option in login.defs) # auth optional pam_group.so # Uncomment and edit /etc/security/time.conf if you need to set # time restrainst on logins. # (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs # as well as /etc/porttime) # account requisite pam_time.so # Uncomment and edit /etc/security/access.conf if you need to # set access limits. # (Replaces /etc/login.access file) # account required pam_access.so # Standard Un*x account and session account required pam_unix.so session required pam_unix.so # Sets up user limits, please uncomment and read /etc/security/limits.conf # to enable this functionality. # (Replaces the use of /etc/limits in old login) # session required pam_limits.so # Prints the last login info upon succesful login # (Replaces the `LASTLOG_ENAB' option from login.defs) session optional pam_lastlog.so # Prints the motd upon succesful login # (Replaces the `MOTD_FILE' option in login.defs) session optional pam_motd.so # Prints the status of the user's mailbox upon succesful login # (Replaces the `MAIL_CHECK_ENAB' option from login.defs). You # can also enable a MAIL environment variable from here, but it # is better handled by /etc/login.defs, since userdel also uses # it to make sure that removing a user, also removes their mail # spool file. session optional pam_mail.so standard noenv # The standard Unix authentication modules, used with NIS (man nsswitch) as # well as normal /etc/passwd and /etc/shadow entries. For the login service, # this is only used when the password expires and must be changed, so make # sure this one and the one in /etc/pam.d/passwd are the same. The "nullok" # option allows users to change an empty password, else empty passwords are # treated as locked accounts. # # (Add `md5' after the module name to enable MD5 passwords the same way that # `MD5_CRYPT_ENAB' would do under login.defs). # # The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in # login.defs. Also the "min" and "max" options enforce the length of the # new password. password required pam_unix.so nullok obscure min=4 max=8 # Alternate strength checking for password. Note that this # requires the libpam-cracklib package to be installed. # You will need to comment out the password line above and # uncomment the next two in order to use this. # (Replaces the `OBSCURE_CHECKS_ENAB', `CRACKLIB_DICTPATH') # # password required pam_cracklib.so retry=3 minlen=6 difok=3 # password required pam_unix.so use_authtok nullok md5
This is from my Debian laptop (mars.starshine.org) and thus has far more comments (all those lines starting with "#" hash marks) than those that Red Hat installs. It's good that Debian comments these files so verbosely, since that's practically the only source of documentation for PAM files and modules.
In this case the entry that you really care about is the one for 'securetty.so' This module checks the file /etc/securetty which is classically a list of those terminals on which your system will allow direct root logins.
You could comment out this line in /etc/pam.d/login to disable this check for those services which call the /bin/login command. You can look for similar lines in the various other /etc/pam.d files so see which other services are enforcing this policy.
This leads us to the question of why your version of 'su' is not working. Red Hat's version of 'su' is probably also "PAMified" (almost certainly, in fact). So there should be a /etc/pam.d/su file that controls the list of policies that your copy of 'su' is checking. You should look through that to see why 'su' isn't allowing your 'webmaster' account to become 'root'.
It seems quite likely that your version of Red Hat contains a line something like:
# Uncomment this to force users to be a member of group root # before than can use `su'. You can also add "group=foo" to # to the end of this line if you want to use a group other # than the default "root". # (Replaces the `SU_WHEEL_ONLY' option from login.defs) auth required pam_wheel.so
Classically the 'su' commands on most versions of UNIX required that a user be in the "wheel" group in order to attain 'root' The traditional GNU implementation did not enforce this restriction (since rms found it distasteful).
On my system this line was commented out (which is presumably the Debian default policy, since I never fussed with that file on my laptop). I've uncommented here for this example.
Note that one of the features of PAM is that it allows you to specify any group using a command line option. It defaults to "wheel" because that is an historical convention. You can also use the pam_wheel.so module on any of the PAMified services --- so you could have programs like 'ftpd' or 'xdm' enforce a policy that restricted their use to members of arbitrary groups.
Finally note that most recent versions of SSH have PAM support enabled when they are compiled for Linux systems. Thus you may find, after you install any version of SSH, that you have an /etc/pam.d/ssh file. You may have to edit that to set some of your preferred SSH policies. There is also an sshd_config file (mine's in /etc/ssh/sshd_config) that will allow you to control other ssh options).
In generall the process of using ssh works something like this:
- Install the sshd (daemon) package on your servers (the systems that you want to access)
- Install the ssh client package on your clients (the systems from which you'd like to initiate your connections).
- Generate Host keys on all of these systems (normally done for you by the installation).
.... you could stop at this point, and just start using the ssh and slogin commands to access your remote accounts using their passwords. However, for more effective and convenient use you'd also:
- Generate personal key pairs for your accounts.
- Copy/append the identity.pub (public) keys from each of your client accounts into the ~/.ssh/authorized_keys files on each of the servers.
This allows you to access those remote accounts without using your passwords on them. (Actually sshd can be configured to require the passwords AND/OR the identity keys, but the default is to allow access without a password if the keys work).
Another element you should be aware of is the "passphrases" and the ssh-agent. Basically it is normal to protect your private key with a passphrase. This is sort of like a password --- but it is used to decrypt or "unlock" your private key. Obviously there isn't much added convenience if you protect your private key with a passphrase so that you have to type that every time you use an ssh/slogin or scp (secure remote copy) command.
ssh-agent allows you to start a shell or other program, unlock your identity key (or keys), and have all of the ssh commands you run from any of the descendents of that shell or program automatically use any of those unlocked keys. (The advantage of this is that the agent automatically dies when you exit the shell program that you started. That automatically "locks" the identity --- sort of.
There are alot of other aspects to ssh. It can be used to create tunnels, through which one can use all sorts of traffic. People have created PPP/TCP/IP tunnels that run through ssh tunnels to support custom VPNs (virtual private networks). When run under X, ssh automatically performs "X11 forwarding" through one of the these tunnels. This is particularly handy for running X clients on remote systems beyond a NAT (IP Masquerading) router or through a proxying firewall.
In other words ssh is a very useful package quite apart from its support for cryptographic authentication and encryption.
In fairness I should point out that there are a number of alternatives to ssh. Kerberos is a complex and mature suite of protocols for performing authentication and encryption. STEL is a simple daemon/client package which functions just like telnetd/telnet --- but with support for encrypted sessions. And there are SSL enabled versions telnet and ftp daemons and clients.
Another issue where I talked a bit about crypto software available for Linux:
http://linuxgazette.net/issue35/tag/crypto.html
Another issue where I answer questions about remote root logins:
http://linuxgazette.net/issue35/tag/remoteroot.html
|
|
|
Hey all, I have users that need root access to their workstations. Reading the pam documentation for the pam_wheel module it sounds like I can allow them to 'su -' without entering a password. This is ideal because I don't want to give them that root password, i'd rather keep that to myself. Problem is, it doesn't work. I'm using red hat 7.2. Here is the contents of /etc/pam.d/su:
Subject: pam_wheel List-id: Pluggable Authentication Modules <pam-list.redhat.com> #%PAM-1.0 auth sufficient /lib/security/pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. auth sufficient /lib/security/pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required /lib/security/pam_wheel.so use_uid auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_xauth.soHere is output from the id command as a user:uid=976(jabagley) gid=100(users) groups=100(users),0(root),98(ident)when 'su -' is entered, i am prompted for a password. Did I missunderstand the pam documentation? what is wrong?thanks, -- James Bagley | CDI Innovantage james_bagley@xxxxxxxxxxxxxxx | Technical Computing UNIX Admin Support DON'T PANIC | Agilent Technologies
|
|
|
You MUST restrict authentication to services that are explicitly specified. The 'other' fallback
MUST be disabled by specifying the pam_deny.so module for each module-type in the 'other'
configuration. This ensures that access decisions within the PAM system are handled only by the
service specific PAM configuration.You MUST add the pam_wheel.so module to the 'auth' module type configuration for the 'su'
service and specify the 'trusted' group.Sample /etc/pam.d/su File
File: /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_wheel.so use_uid group=trusted
auth required pam_unix2.so
auth required pam_tally.so onerr=fail no_magic_root
account required pam_unix2.so
account required pam_tally.so no_magic_root # deny=5 reset
password required pam_unix2.so
session required pam_unix2.so
Forcing the root user to change the root password is not desired here, therefore the pam_pwcheck.so
module is absent.
|
|
|
-rwxr-xr-x 1 root root 7088 Apr 23 03:03 /lib64/security/pam_wheel.so
|
|
|
" RainBeware of the garbage can "wheel group in linux
So I was wondering if I could set "su" to only allow users in the "wheel" group to su to root like with BSD. I never thought I'd be lucky enough to find another reason why Richard Stallman (the hippy who started the FSF) is an idiot in the process.
The man page pointed me to the info page, which had a very, um, intresting bit of text at the bottom..Why GNU `su' does not support the `wheel' group
===============================================(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
So this is how I understand what he is saying:We have bob, mary, and joe all as members of the "wheel" group, all who have the root password.
Bob gets pissed off because someone symlinked vim to emacs and changes the root password, not telling anyone else what it is.
Jack (standard user, not in wheel group) somehow finds the password from bob, but is unable to do anything because he is not in the wheel group
Everyone is screwed
So lets see, if a non-admin user somehow gets the root password we dont WANT him logging into root. If they dont understand how to administer a unix box they'll most likely end up running 'rm -rf /'. Assuming bob removed all users but himself from the wheel group, if the require-wheel feature was disabled then Jack could supposedly tell one of the legitamate administrators what the password is so they could regain control of the system, but how likely is it that Mr. pissed off Bob would tell Jack the password unles he had good reason, which would most likely imply that he trusted him not to turn against him. And if bob added Jack himself to the wheel group Jack could just log into his account, and call over an admin to su to root and take care of the situation. I just dont see how this weighs up.Addionally, he totally ignores the fact that this command is now used on many production buisness servers. In these situations you are much more worried about your users (or intruders) gaining root access than a discruntle employee. I would accept the feature being turned off by default, but not including it for this reason? Come on.
Fortunetly, I found theres a PAM module written by one of the friendly RedHat folks that adds wheel checking support.
Add the following lines to /etc/pam.d/su:
auth required /lib/security/pam_wheel.so use_uid
The readme for the pam_wheel module is avaliable here.And if you're REALLY parinoid, check out the new SELinux features in Kernel 2.6 which allows you to get rid of the whole concept of a superuser alltogether.
This entry was posted on Friday, April 30th, 2004 at 8:29 pm and is filed under Rants, Computers & Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
...
Kdzhao03-15-02, 10:51
Hi, From a book, I see it mentioned that we can use the "wheel" group to
restrict those users who can su to root.(as below). However, is that for
Solaris? I tried to add the "wheel" group but seems no use. By the way,
I also
did not see the /etc/ttytab file on my system (what is this file about?).
Anyone
has any idea on this?
My current way to limit people who can su to root is to modify the
"/usr/bin/su" so that only group member can exec it, others can not. Is
there
any better way on it?
Thanks.
===(attach)=====
Limit who can become root by using the "wheel" group in the /etc/group
file. If the wheel group is empty, anyone can switch user (su) to root if
they know
the password. However, if there are any entries in the wheel group, only
those
users listed can su to root. This stops an unauthorised user who happens
to learn
the root password from becoming root. However, if someone does know the
root
password, they still will be able to log in directly as root if the /etc/ttytab
file is not configured correctly. In the /etc/ttytab file, change the field
"secure" to "unsecure" for all entries. This forces all
users to login as an ordinary user then su to root and /etc/ttytab can now
work in
conjunction with the wheel group to control access to root. Another advantage
of
forcing users to su to root is it leaves a better audit trail of who has
performed
system administrator actions.
--------------------------------------------------------------------------------
John D Groenveld03-15-02, 10:51
In article <[email protected]>, kdzhao
<[email protected]> wrote:
> My current way to limit people who can su to root is to modify the "/usr/bin/su"
> so that only group member can exec it, others can not. Is there any better
way
> on it?
As you discovered, the wheel group does not exist in Solaris 2.
http://groups.google.com/ group:comp.unix.solaris su wheel
The best way to limit su access is not to give the root password away. If
you need to
delegate sys admin functions, read about sudo and RBAC. John [email protected]
--------------------------------------------------------------------------------
Greg Andrews03-15-02, 10:51
[email protected] (kdzhao) writes:
>
> From a book, I see it mentioned that we can use the "wheel" group to restrict
> those users who can su to root.(as below). However, is that for Solaris?
No. The book was written for a BSD type of Unix operating system. SunOS
4.x (commonly
called "SunOS", though Sun included it in Solaris 1.1 and 1.2) was a BSD
Unix, but
it's quite old now.
SunOS 5.x is what people usually call "Solaris". It is an SVR4 type Unix,
which does
not use the wheel group.
-Greg
--
+++++ Greg Andrews +++ [email protected] +++++ I have a map of the United States
that's
actual size -- Steven Wright
--------------------------------------------------------------------------------
Simon Burr03-15-02, 10:51
In <[email protected]> [email protected]
(kdzhao) writes:
> From a book, I see it mentioned that we can use the "wheel" group to restrict
> those users who can su to root.(as below)
This is fairly standard on BSD stuff; however Solaris is mainly based around
SVR4
(System V, Release 4) so the stuff isn't going to work exactly as described
below. If
you do want to implement this then you can do the following:
o Add the wheel group to the system:
# groupadd wheel
o Change the permissions of su so that only root and people in the wheel
group can
execute it:
# chown root:wheel /usr/bin/su chmod 4550
o Add allowed users to the wheel group by adding the usernames to the end
of the
wheel entry in /etc/group, ie: Original entry (where GID is the numeric
group id):
wheel::GID: With users foo, bar and baz added to the wheel group:
wheel::GID:foo,bar,baz
You can also use a PAM module to enforce this; you can get the code for
the PAM
module from: http://www.science.uva.nl/pub/solaris/su_group0.c.gz
--
Simon the stressed http://www.bpfh.net/ [email protected] "Our company name
changes
so often we have to use plain mugs and PostIt notes"
--------------------------------------------------------------------------------
Alan Coopersmith03-15-02, 14:02
[email protected] (kdzhao) writes in alt.solaris.x86:
| From a book, I see it mentioned that we can use the "wheel" group
|to restrict those users who can su to root.(as below). However, is |that
for
Solaris? I tried to add the "wheel" group but seems no use. |By the way,
I also did
not see the /etc/ttytab file on my system (what |is this file about?). Anyone
has any
idea on this?
Sounds like your book covers BSD and not Solaris. If you want to implement
group
wheel on Solaris, search on groups.google.com for pointers in comp.unix.solaris
to
Casper Dik's PAM module for doing this.
The CONSOLE field in /etc/default/login is the Solaris equivalent to the
ttytab
functionality you described.
04-01-2002, 12:10 AM Note: this document is written in reference to Red Hat Linux 6.2+ PAM (Pluggable authentication module) is very diverse in the types of modules it provides. One could accomplish many authentication tasks using PAM. However PAM expands itself beyond typical authentication programs, as it allows an admin to employ other system-critical features such as resource limiting, su protection, and TTY restrictions. Much of PAM's features are not within the scope of this document, but for further reading you can refer to the links at the bottom of this document. Firstly we must enable the pam_limits module, inside /etc/pam.d/login. Add the following to the end of the file: session required /lib/security/pam_limits.so After adding the line above, the /etc/pam.d/login file should look something like this: #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so session required /lib/security/pam_limits.so The limits.conf file located under the /etc/security directory can be used to control and set resource policies. limits.conf is well commented and easy to use - so do take the time to skim over its contents. It is important to set resource limits on all your users so they can't perform denial of service attacks with such things as fork bombs, amongst other things it can also stop 'stray' server processes from taking the system down with it. It is also a good idea to separate rules for users, admins, and other (other being everything else). This is important, cause take for instance a scenario where a user fork bombs the system - it could in effect disable an administrator's ability to login to the system and take proper actions, or worse crash the server. Below is the default policy used on a server iv configured: # For everyone (users and other) * hard core 0 * - maxlogins 12 * hard nproc 50 * hard rss 20000 # For group wheel (admins) @wheel - maxlogins 5 @wheel hard nproc 80 @wheel hard rss 75000 #End of file The first set of rules say to prohibit the creation of core files - core 0 , restrict the number of processes to 50 - nproc 50, restrict logins to 12 - maxlogins 12, and restrict memory usage to 20MB - rss 20000 for everyone except the super user. The the later rules for admins, say to restrict logins to 5 - maxlogins 5, restrict the number of processes to 80 - nproc 80, and restrict the memory usage to 75MB - rss 75000. All the above only concerns users who have entered via the login prompt on your system. The asterisk (*) defines all users and at wheel (@wheel) defines only users in group wheel. Make sure to add your administrative users into the wheel group (this can be done in /etc/group). Finally edit the /etc/profile file and change the following line: ulimit -c 1000000 to read: ulimit -S -c 1000000 > /dev/null 2<&1 This modification is used to avoid getting error messages like 'Unable to reach limit' during login. On newer editions of Red Hat Linux, the later ulimit setting is default. Further reading is available in The Linux-PAM System Administrators' Guide located at: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
Google matched content |
The Answer Guy 55 Remote Login as 'root' Don't do it! (Except using SSH or ...)
The pam_wheel PAM module limits the users who can become the root user based on the original users' group memberships. Groups of users can be implicitly trusted or explicitly distrusted based on the combination of options (described below) that are specified when pam_wheel is configured.
The following options are supported:
Example:
su auth sufficient pam_rootok.so
su auth required pam_wheel.so
su auth required pam_unix.so
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
