Go Premium for a chance to win a PS4. Enter to Win


How do you configure RHEL 4.0 to allow the "root" account to set a screensaver?

Posted on 2006-10-23
Medium Priority
Last Modified: 2007-12-19
Hello.  We are building a lab that is heavy with Red Hat Enterprise Linux 4.0 (Update 2).  As part of our security hardening, we need to be able to allow the local adminstrator accounts (root) to set a screensaver.  RHEL 4.0 by default does not allow this but we know there is a workaround solution (other organizations have successfully done this but consider their techniques to be proprietary).  We haven't stumbled on to the magic formula yet.

Does anyone know how to allow the root account to set screensavers?
Question by:L3MS
LVL 40

Accepted Solution

noci earned 1200 total points
ID: 17791760
Think about it a little...

Why would you like a screen save for root....
- you shouldn't work under the root account (regularly)
  use sudo for the tasks where root access IS required.
- Why waste resources of servers on showing some pretty pictures etc.
  (other than the BLACK-screen screen saver that is) while not using the

So there is a reason for not having a screensaver by default.
that said..

you can run a screen saver by: xscreensaver
and it will tell you this:

xscreensaver: initial effective uid/gid was root/root (0/0)
xscreensaver: running as nobody/nobody (65534/65534)

xscreensaver: This is probably because you're logging in as root.  You
              shouldn't log in as root: you should log in as a normal user,
              and then `su' as needed.  If you insist on logging in as
              root, you will have to turn off X's security features before
              xscreensaver will work.

              Please read the manual and FAQ for more information:


I hope this helps.

Author Comment

ID: 17795469

Thank you for your response.  I guess I should answer your questions as to why I need this done.

The Linux Systems I am working on are for the U.S. Government and as such, they will be part of a classified network.  Hence, they will fall under NISPOM Chapter 8 requirements for security hardening.  One of those requirements is that screensavers cannot be blank.

Since the root account cannot set a screensaver, it is conceivable that an administrator could be logged in as "root" (something we do quite a bit in order to load and maintain certain software packages) , could leave the machine and forget that they were logged in.  Without a screensaver lock, anyone could then sit down at that machine and work the system with local administrative privileges.  That is a potential security breech that is not permissable under NISPOM Chapter 8.

A better way to explain it would be a comparison to the Windows OS.  In Windows, I can go in and modify certain registry settings so that no matter who is logged on (local or domain), a locked screensaver will come up after a certain amount of idle time.  I can also set it so that the same exact screensaver comes up for everybody who uses that machine.  I would like to be able to do the same thing with my RHEL 4.0 Systems.

I am currently looking through the links you provided to see if any such procedure is possible.

LVL 40

Expert Comment

ID: 17795715
If you want to setup a secure environment 1st look into security enhanced version of linux (Enguarde linux, selinux kernels of RedHat etc)
From the root account there is ABSOLUTELY no guarantee about anything,
that's what the root account is built like in unix YOU CAN DO ANYTHING.

the only thing you can do is setup syslog logging to an external machine
and have that machine inaccessible by the same people that run the
other systems. Lack of certain logging means compromise, and the last logging will show when it happened.

That said there always is the problem WHO is root, was it john, joe, whoever,
C.R. Acker? So the next best thing is to firbid the use of root., Have it's password set to a Real Random String of say 20-25 characters (some unices are limited to 8),
(base64 encoding of some output of /dev/random?) and store those passwords in sealed enveloppes in a safe, (if needed to be opened by two different people present at the same time).
To handle special tasks like installing software etc. use SUDO,
where john & joe are actualy logged when the action takes place.
Also setup sudo when special privileges are needed, f.e. make a backup.
Like, the backup account IS allowed to tar the whole system with root privileges.

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

LVL 11

Expert Comment

ID: 17812312
You should be using SuperUser for this.

man su
LVL 40

Expert Comment

ID: 17815551
For su you still need to know the password of root, with sudo you dont and you can set policies on what commands can be run under what account; possibly root,
but also f.e. restrict oracle-DBA's to use their own account and not 'oracle' and
have the export & start/stop use through sudo)
LVL 11

Expert Comment

ID: 17819365
su is an alias for sudo my friend.
LVL 40

Expert Comment

ID: 17819922
su is quite different from sudo...

ls -l /bin/su
-rws--x--x 1 root root 24812 Oct 17 20:32 /bin/su

ls -l /usr/bin/sudo
---s--x--x 1 root root 104520 Jun 14 17:12 /usr/bin/sudo

Please compare 'man su' and 'man sudo'

with su you can become another user if you know the credentials of the other user or if you are root.

with sudo you can execute programs on behalf of the other user. And optional you need your OWN
password to do that. one of the programs that you can execute might be a shell.
In that case sudo looks like su.

So they are quite different.  
su comes from the shadow package: http://shadow.pld.org.pl/
sudo comes from the sudo package: http://www.sudo.ws/

LVL 30

Expert Comment

by:Kerem ERSOY
ID: 17841933
To make a long story shory. The screensaver used in RedHAT does not allow to be run as root. To achieve this the best idea is to set-up sudo as noci pointed and use another standard user for admininstration. In fact today most modern desktop implementations do the same and ban root from logged on to the GUI interface.

PS- NISPOM is not clear about how to logon a system but There are several references to need-to-know etc. If we interpret it in the essence as a general rule you must not use root to logon a system. Thsi will decrease the efficiency of audit trailing.

You can check ubuntu linux even grab a CD copy:


Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Hello EE, Today we will learn how to send all your network traffic through Tor which is useful to get around censorship and being tracked all together to a certain degree. This article assumes you will be using Linux, have a minimal knowledge of …
Fine Tune your automatic Updates for Ubuntu / Debian
Want to learn how to record your desktop screen without having to use an outside camera. Click on this video and learn how to use the cool google extension called "Screencastify"! Step 1: Open a new google tab Step 2: Go to the left hand upper corn…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
Suggested Courses
Course of the Month11 days, 15 hours left to enroll

916 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question