xscreensaver error

[pack1]

When I log out of X I see this message:

xscreensaver: SIGHUP received: restarting...
xscreensaver: initial effective uid/gid was root/pack (0/1002)
xscreensaver: running as pack/pack (1002/1002)

How can I get rid of this message?

 

[pack1]

I dont recall seeing it before. It showed up after I added a new user (pack) and deleted the old one. I have "xscreensaver &" in my .xinitrc.

Btw if anyone can help, why does the old user's file and folders still show up when I use the locate command? I already rmuser and deleted the home dir of old user.

 

[Crusty]

How did you add a new user and delete the old one?

 

[pack1]

adduser/rmuser like so:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/users-modifying.html

rmuser didnt delete the home dir though so I removed it manually with rm -rf.

 

[Crusty]

If you want to update locate so it finds your new files you need to run updatedb (at least in Linux, not sure of FreeBSD).

Are you using any sort of login manager like kdm, gdm, xdm?

Or are you manually starting X via startx when you login.

 

[pack1]

Yeah I just figured out the locate database

Just manually starting X here.

 

[Crusty]

http://infocom.cqu.edu.au/Courses/aut2001/85321/Resources/Study_Guide/Chapter_5/

I just found that using some quick google searching.

Process UID and GID

In order for the operating system to know what a process is allowed to do it must store information about who owns the process (UID and GID). The UNIX operating system stores two types of UID and two types of GID.
Real UID and GID

A process' real UID and GID will be the same as the UID and GID of the user who ran the process. Therefore any process you execute will have your UID and GID.

The real UID and GID are used for accounting purposes.
Effective UID and GID

The effective UID and GID are used to determine what operations a process can perform. In most cases the effective UID and GID will be the same as the real UID and GID.

However using special file permissions it is possible to change the effective UID and GID. How and why you would want to do this is examined later in this chapter. The following exercise asks you to create an executable program we will use to display the real and effective UID and GID.

Effective UID and GID

In this section we revisit the discussion of the relationship between the process attributes of real UID/GID and effective UID/GID.

When you use the passwd command to change your password the command will actually change the contents of either the /etc/passwd or /etc/shadow files. These are the files where your password is stored. By default most Linux systems use /etc/passwd

As has been mentioned previously the UNIX operating system uses the effective UID and GID of a process to decide whether or not that process can modify a file. Also the effective UID and GID are normally the UID and GID of the user who executes the process.

This means that if I use the passwd command to modify the contents of the /etc/passwd file (I write to the file) then I must have write permission on the /etc/passwd file. Let's find out.

What are the file permissions on the /etc/passwd file?

dinbig:~$ ls -l /etc/passwd
-rw-r--r-- 1 root root 697 Feb 1 21:21 /etc/passwd

On the basis of these permissions should I be able to write to the /etc/passwd file?

No. Only the user who owns the file, root, has write permission. Then how do does the passwd command change my password?
setuid and setgid

This is where the setuid and setgid file permissions enter the picture. Let's have a look at the permissions for the passwd command (first we find out where it is).

dinbig:~$ which passwd
/usr/bin/passwd
dinbig:~$ ls -l /usr/bin/passwd
-rws--x--x 1 root bin 7192 Oct 16 06:10 /usr/bin/passwd

Notice the s symbol in the file permissions of the passwd command, this specifies that this command is setuid.

The setuid and setgid permissions are used to change the effective UID and GID of a process. When I execute the passwd command a new process is created. The real UID and GID of this process will match my UID and GID. However the effective UID and GID (the values used to check file permissions) will be set to that of the command.

In the case of the passwd command the effective UID will be that of root because the setuid permission is set, while the effective GID will be my group's because the setgid bit is not set.

 

[Crusty]

As far as I can tell, that message is harmless

 

[pack1]

I get the part you pasted MCrusty. I do a "ls -l /usr/X11R6/bin/xscreensaver" and it is owned by root:wheel. User pack is in wheel group so I dont understand why I am getting that message.

 

[drag]

unless you notice something wrong with xscreensaver, just ignore the message.

It's not even a error message, it's just stating that xscreensaver is running under a different user account.

In Linux every application runs under a user account. That message is probably generated when you startx and run xscreensaver. Since there can only be one instance of xcreensaver running (you don't want 2 xscreensavers running right?) the old one kills itself when the second one starts.

Xscreensaver is probably started some time before that underneath a root account.

Stuff like that is best ignored unless your actually having problems with a program. Most dialog stuff, and startup stuff can be ignored. It's only usefull if your having issues.


For the locate command....

Locate command doesn't actually scan the directory system. It uses a database of files that are generated from the updatedb command, which generally runs as 'cron' job.

Just run updatedb and locate will reflect the newer changes in the directory system.