Cannot startx unless Superuser

English Install/Boot/Login
#1

So I have a box and a laptop

The box is 64 bit and the laptop 32

I download 11.4 for the first time and do a dualboot, clean install

Please note that I have setup many dualboot systems sucessfully, and this is NOT the problem. I can confidently say that.

The 64 bit wouldn’t let me startx unless I was su.

…thought maybe is was a bad download or something. Downloaded the 32bit for the laptop, logged in, same problem w/ the same output.

Please note I always boot to runlevel three.

this is an example of what I get:

Login: ****
Paswword: ***
startx

xauth: file /home/****//.serverauth.1881 does not exist

Fatal Server Error:
Cannot move old log file “/var/log/Xorg.0.log” to “/var/log/Xorg.0.log.old”

Please consult the X.org Foundation support
at Novell Login
for help

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

xinit failed. /usr/bin/Xorg is not setiud, maybe that’s the reason?
if so either use display manager (strongly recommended) or adjust /etc/permissions.local

Questions :

  1. Is it becasue I’m booting into runlevel three and something changed in between 11.3 and 11.4?

  2. Do I need to manually move “/var/log/Xorg.0.log” to “/var/log/Xorg.0.log.old” ?

  3. /usr/bin/Xorg is not setiud could this be the problem, I’m not really sure I know what this even is…

  4. Do I need to chmod my permissions?

Please also understand that I’ve been playing with Linux (primarily opensuse, by the way) for about 13 months now, so I know I have a lot to learn still. I know I can fix this w/ a bit of guidance,

thanks in advance - Cheers

#2

subcook69420, I actually had the same problem with openSUSE 11.4 M6, which had a bad DVD posted online. I managed to make the DVD, but ran into this issue. Searching on-line I did find a solution, but the actual problem was a BAD dvd. I don’t remember what I did any more, but I would ask if you double checked to make sure the m5d checksum is correct? Basically, you can get a bad download or you can make a bad DVD or CD burn which can corrupt some important files. I did not get this error when using the final release of openSUSE 11.4.

Thank You,

#3

Hi
It’s not an error, it’s by design for 11.4

#4

Hi
Forgot to add the link…
How to start x properly?

#5

I had this myself and I can’t quite remember the exact steps that fixed it, or even be a 100% sure which was the actual thing cos I did a few things, but it went something like this:

xauth: file /home/****//.serverauth.1881 does not exist

I thought that being it looking for a previous session file, not much I could do about that (that I know of, someone else may enlighten us), so I ignored it

Cannot move old log file “/var/log/Xorg.0.log” to “/var/log/Xorg.0.log.old”

Either Xorg.log doesn’t exist or there’s a permissions problem, or there’s an existing Xorg.0.log.old that for some reason can’t be over-written

So I dropped out of kdm and into a console login as root, copied both files to Xorg.blah.disabled, checked the copies were created, then removed the originals with rm -f Xorg.blah for each one

I then did vi /var/log/Xorg.0.log as root (I seem to remember this being because it couldn’t find the log file when attempting to restart x, the vi command makes a new empty log file)

At some point there was an error about the .Xauthority file in the user’s home directory, so I made a .disabled copy of this and removed the original, much the as with the Xorg.0.log file

So, vi .Xauthority as the user in the user’s home directory and restarted x

There were several x restarts along the way whilst doing this and I had to rename one of the files back from the.disabled version to the original, I think it may have been the .Xauthority (it’s a hidden file so you won’t see it in your file manager without enabling show hidden files)

Sorry I can’t be more specific about which step actually solved it, but without reproducing the problem I can’t do it again and pay more attention, now I fixed it I have no idea how to break it again :stuck_out_tongue:

But if you copy the original files to something like .disabled first as I did before removing them, you can always copy them back so even if it doesn’t work you can go back to where you were at any point, nothing ventured, nothin gained, and as long as you back up the files you’re tinkering with first, nothing lost

I have noticed a couple of permissions quirks in 11.4 myself, aside from this x one most noticeably with virtualbox, I’ve had to reset permissions on the VirtualBox binary 3 times cos it somehow got reset so that to no-one not even root could execute it after a restart, one for a bug report maybe?

#6

So to get to the jist of all of this, we can not longer run startx as a normal user, but must be a root user. The reason for this is that the file /use/bin/Xorg no longer has the setuid bit set. Based on the message pointed to, you could derive this from the information:

<bmwiedemann1> malcolmlewis: maybe you can just re-add the suid bit. /etc/permissions.local has a line for Xorg
<bmwiedemann1> # setuid bit on Xorg is only needed if no display manager, ie startx  is used. Beware of CVE-2010-2240

If you find the file /etc/permissions.local, this is what it says:

#
# /etc/permissions.local
#
# This file is used by SuSEconfig and chkstat to check or set the modes
# and ownerships of files and directories in the installation.
#
# In particular, this file will not be touched during an upgrade of the
# SuSE Linux installation. It is designed to be a placeholder for local
# additions by the administrator of the system to reflect filemodes
# of locally installed packages or to override file permissions as
# shipped with the distribution.
#
# Format:
# <file> <owner>:<group> <permission>
#
# Please see the file /etc/permissions for general usage hints of the
# /etc/permissions* files.
# Keep in mind that this file (/etc/permissions.local) is being used by
# default by SuSEconfig, the shell script that is used by yast and yast2
# after package installation and configuration changes to make the changes
# effective for the respective packages (eg generating the "real"
# configuration files).
# Always check if there are no conflicts between your "local" changes here
# and the settings in the other permissions files by calling
# "SuSEconfig" as root!
# Please remember that logfiles might be modified by the logfile
# rotation facilities (e.g. logrotate) so settings entered here might
# be overridden.
# This file needs to end with a newline.
#

#
# suexec is only secure if the document root doesn't contain files
# writeable by wwwrun. Make sure you have a safe server setup
# before setting the setuid bit! See also
# https://bugzilla.novell.com/show_bug.cgi?id=263789
# http://httpd.apache.org/docs/trunk/suexec.html
#
#/usr/sbin/suexec2            root:root       4755

# setuid bit on Xorg is only needed if no display manager, ie startx
# is used. Beware of CVE-2010-2240.
#
/usr/bin/Xorg                 root:root       4711

I took the # off of the last line and I presume if you run the command “/usr/bin/Xorg root:root 4711” that this sets the setuid bit on the Xorg file. I guess on each reboot, this file would set that same bit. I decided to just do this manually, and sure enough, startx now works for me.

Thank You,

#7

Hi
Yes, but as the note says…beware CVE - CVE-2010-2240 (under review)

#8

Hi
Yes, but as the note says…beware CVE - CVE-2010-2240 (under review)
Yes malcolmlewis I did read through it and thank you for pointing it out. It does not seem to mention kernels 2.6.37 or 2.6.38 and I wonder if that will make any difference in this in the future? I had found this before and used it to fix my previous openSUSE milestone 6 installation, but this happened due to X not starting in the first place, but for other reasons. I guess that I did not realize it was for the final release as I have had no occasion to run startx since then. That in its self is kind of funny as I did used to use startx a lot when loading the nVIDIA video driver. I would do a init 3, load the driver as root and then log out, back in as me and run startx. Now, I most often am reloading the video driver after doing a kernel update, which I do right after a complete restart. It is kind of funny what drives your habits on your local PC. In any event, thanks for the information malcolmlewi.

Thank You,

#9

Hi
When I do an nvidia update I have always used init 5 && exit which will take you back to the login screen or your desktop if it’s set to auto login :wink:

#10

Hi
When I do an nvidia update I have always used init 5 && exit which will take you back to the login screen or your desktop if it’s set to auto login
I must give that a try though I don’t understand what it does at present and it is just about bed time here once again and my mind is slowing down … stating to shutdown on me tonight … too complicated… error … error … :\

Thank You,

#11

I would do a init 3, load the driver as root and then log out, …

When using init 3 to switch off X for maintanance, why not using init 5 to go back. That is symetric.

IMHO the next is good working practice:
. Let all users log out of the GUI (for most this is simple, needs only coordination with yourself :wink: )
. Do Ctrl-Alt-F1 to go to the console and login in and change to root;
. do* init 3*;
. do the maintanance;
. do* init 5*.
Now you can go back to logical screen 7 (but I guess it becomes visible by itself) and check. Do not forget lo log out in logical screen 1, but you may stay loged in there as long as you are busy doing the testing and changing cycle.

And the above has no need for startx do be done at all.

#12

malcolmlewis,

I’ve encountered a very similar problem.

The only difference is -
I’,m using KDM instead of startx. KDM will fail to come up during a reboot. Cold start will see not such problem. The error message when encountered, is exactly the same as mentioned by subcook69420 in this original post.

Appreciate if you could visit my post and give me a pointer.
Thanks.

#13

@subcook69420
From what I remember /home/****//.serverauth.1881 changes every time like maybe 1881 is the process id (pid).

If you are “always” booting into init 3 (runlevel 3) is that your intention or is it because you are stopped at init 3 when you reboot?
If you init 3 then you shouldn’t have xlog issues but because you run startx I’m assuming you want the GUI for userid.

You might need to change ownership.
When you startx as root there’s no problem, the root gets a clean GUI screen?
If that’s true, then I would make sure that in the userid’s home directory all files belong to userid and group users.


ls -halF  /home/userid
####   if your .Xauthority or .ICEauthority do not have userid and users as group then as superuser
su -c "chown  userid:users   /home/userid/.Xauthority    /home/userid/.ICEauthority" 
password:

Not sure which /var/log/Xorg.log is there but IMO if root gets the GUI but ordinary userid doesn’t its not a Xorg issue.

Are there an error message or two posted before the login prompt that you haven’t posted.

Also, if the files above are owned by userid:users, you can try renaming the files to something like /home/userid/ORIGXauthority and /home/userid/ORIGICEauthority to see if openSUSE generates new files for the ordinary userid.

#14

I think you guys are overlooking one simple fact. It may be as simple as permissions of the /tmp directory. My /tmp directory had to be moved to another drive and that is when my problems started. On my laptop, it is set as
drwxrwxrwt. On my desktop it was set as drwx rw rw … I just changed it to 777, but do not know how to change the last attribute to t, or what t even is, but I’m betting once permissions are correct for /tmp, my problems go away.

#15

On Sat, 13 Aug 2011 04:26:02 +0000, lshantz wrote:

> I think you guys are overlooking one simple fact. It may be as simple as
> permissions of the /tmp directory. My /tmp directory had to be moved to
> another drive and that is when my problems started. On my laptop, it is
> set as
> drwxrwxrwt. On my desktop it was set as drwx rw rw … I just changed it
> to 777, but do not know how to change the last attribute to t, or what t
> even is, but I’m betting once permissions are correct for /tmp, my
> problems go away.

According to ‘man chmod’:

The restricted deletion flag or sticky bit is a single bit, whose
interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory
unless they own the file or the directory; this is called the
restricted deletion flag for the directory, and is commonly found on
world-writable directories like /tmp. For regular files on some older
systems, the bit saves the program’s text image on the swap device so
it will load more quickly when run; this is called the sticky bit.

This man page also explains how to set it.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

#16

On Fri August 12 2011 11:26 pm, lshantz wrote:

>
> I think you guys are overlooking one simple fact. It may be as simple as
> permissions of the /tmp directory. My /tmp directory had to be moved to
> another drive and that is when my problems started. On my laptop, it is
> set as
> drwxrwxrwt. On my desktop it was set as drwx rw rw … I just changed
> it to 777, but do not know how to change the last attribute to t, or
> what t even is, but I’m betting once permissions are correct for /tmp,
> my problems go away.
>
>
lshantz;

t is the sticky bit, it is set as 1 in the first of the four octets for
example:


chmod 1777 /tmp

or with the t as in:


chmod +t /home/jdoe/nodeletedirectory

t has no effect on files, but limits deletes the contents of a directory to
the owner ( or of course root ). t will not prevent others from changing the
contents but it does prevent others from deleting.

See:
http://en.wikipedia.org/wiki/Sticky_bit
and the manual:
http://www.manpagez.com/man/1/chmod/

P. V.
“We’re all in this together, I’m pulling for you.” Red Green

#17

I know that this is a security feature, but has anyone found a solid work around for this ?

#18

On 08/31/2011 01:36 AM, subcook69420 wrote:
>
> I know that this is a security feature, but has anyone found a solid
> work around for this ?

Boot to run level 3 (type 3 in GRUB options line), log in as your normal user,
open a terminal, and enter the command


sudo chmod a+s /etc/X11/xorg.conf.d

At this point, startx should work. Note: As you have logged into the GUI as
root, all manner of things are probably borked and you should add a new user for
yourself ASAP and transfer your user files to that new user.

#19

So i’ve been out of the loop for quite awhile, obviously (I’m the OP). None of this has worked for me. Though I accept a lot of it is way over my head, I feel like I’m missing something. I boot directly into runlevel 3. I know this thread was established a long while ago, but is there an easy workaround for this for a beginner?

#20

This is an old thread but since it appears first when searching for a workaround, i thought i just post this reply to help the next newbie out.

… excerpt from 11.4 release notes …

The setuid bit on /usr/bin/Xorg is needed for starting X as an unprivileged user, e.g., via startx.
This method has been deprecated for years in favor of using a display manager. Modern environments
rely on device ACLs and polkit privileges, which in turn depend upon consolekit
tracking the active console, which is performed by the display manager.

Users who depend on the old configuration can set the setuid bit themselves in

/etc/permissions.local by removing the comment sign from the following line:

#/usr/bin/Xorg                 root:root       4711
and running SuSEconfig --module permissions afterwards.

… end excerpt …

I have tested it and it works, without doing the above, you can be in runlevel 3 but you wont be able to startx as a normal user. Only root.
This editing of /etc/permissions.local fixes it…