The "suspicious" errors don't give sufficient information

[Ralph Corderoy]

Binary package hint: xorg

Package xorg, version 1:7.5+5ubuntu1 on 10.04 is leaving error messages
in log files, e.g.

    X: /tmp/.X11-unix has suspicious mode (not 1777) or is not a directory, aborting.

They're from debian/local/xserver-wrapper.c.

    if ((statbuf.st_uid != 0) || (statbuf.st_gid != 0)) {
      (void) fprintf(stderr, "X: %s has suspicious ownership (not root:root), "
                     "aborting.\n", X_SOCKET_DIR);
      exit(1);
    }

    if (statbuf.st_mode != (S_IFDIR | X_SOCKET_DIR_MODE)) {
      (void) fprintf(stderr, "X: %s has suspicious mode (not %o) or is not a "
                     "directory, aborting.\n", X_SOCKET_DIR, X_SOCKET_DIR_MODE);
      exit(1);
    }

In both cases it would help a lot, given the number of times these
errors appear on Google, if the message included what the unexpected
value(s) were, e.g.

    X: /tmp/.X11-unix has suspicious mode, 01755 is not 01777, aborting.
    X: /tmp/.X11-unix has suspicious ownership, 1000:0 is not 0:0, aborting.

(If the `%o' were `%#o' too then the error would make clear the numbers are
octal.)

[Bryce Harrington (bryce)]

Hi Ralph,

        Please attach the output of `lspci -vvnn` too.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Ralph Corderoy (ralph-inputplus)]

No log files or PCI listing required as I'm pointing out a clear, easily confirmable, problem with the source code.

[Ralph Corderoy (ralph-inputplus)]

Bryce, can you stop your automatic thing adding tags and making this bug Incomplete? Or explain why they're needed. Thanks.

[Strby (m-strbacka)]

From yesterday I have this problem too. In /etc/init.d/x11-common is this:
SOCKET_DIR=/tmp/.X11-unix
...
set_up_socket_dir () {
  if [ "$VERBOSE" != no ]; then
    log_begin_msg "Setting up X server socket directory $SOCKET_DIR..."
  fi
  if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
    mv $SOCKET_DIR $SOCKET_DIR.$$
  fi
  mkdir -p $SOCKET_DIR
  chown root:root $SOCKET_DIR
  chmod 1777 $SOCKET_DIR
  do_restorecon $SOCKET_DIR
  [ "$VERBOSE" != no ] && log_end_msg 0 || return 0
}
but everytime when I reboot my notebook, the directory is created with mode 3777, sudo chmod 1777 /tmp/.X11-unix didn't change anything. But sudo chmod -s /tmp/.X11-unix successfuly changed the mode to 1777

[Ralph Corderoy (ralph-inputplus)]

Strby, I sympathise, our LUG has a user that sees this error only every few boots rather than consistently, but this is not the correct bug to try and get your problem fixed. This is only about improving the error message when it occurs, not investigating causes of the error occurring. However, you're correct, the problem lies with the 1777. I'll raise another bug for that and report that number here for you and others that follow.

[Ralph Corderoy (ralph-inputplus)]

Strby, bug #623294 covers your issue of setgid not be cleared by 1777.

[Ralph Corderoy (ralph-inputplus)]

Bryce. This is rapidly losing its charm. What do I have to do to stop your bot from making this change over and over. Can it not see it has already done it and been rebutted? Is there some do-not-dare-make-that-change,-bot tag I need add?

[Ralph Corderoy (ralph-inputplus)]

Bryce said "add the tag 'omit' and that will make it stop making automated changes to your bug" so I did. But the evil, rampaging, bot continues to wage war.

[penalvch (penalvch)]

Ralph Corderoy, as the xorg stack syncs with upstream, there is no compelling reason to deviate from them on this. If this is repeatable on xorg trunk, please feel free to file a bug upstream via https://bugs.freedesktop.org/ .

[Ralph Corderoy (ralph-inputplus)]

Hi Christopher, as I stated "They're from debian/local/xserver-wrapper.c" so is freedesktop.org relevant?
If not, please restore importance and status. Thanks.

[penalvch (penalvch)]

Ralph Corderoy, thank you for your comments. I've subscribed Julien Cristau who has submitted work to Debian in the debian/local/xserver-wrapper.c area within the last few years.

Julian Cristau, could you please provide your perspective on this?

[Ralph Corderoy (ralph-inputplus)]

Hi Christopher, it's been about six weeks and Julien Cristau hasn't responded.
Please restore Bryce's settings of status and importance as
this isn't a freedesktop issue AFAICS.

[Ralph Corderoy (ralph-inputplus)]

Hi Christopher, another six weeks have passed and this bug still hasn't had its correct status and importance settings restored. As you changed them, wrongly, it would seem a matter of taking pride in your work that you restore them to Bryce's settings. Or at least reply to my requests with your argument as to why not. No, this is not an April Fool's. :-)

[penalvch (penalvch)]

Ralph Corderoy, as this is requesting a fundamental change as per the Bug Description, the fix would want to come from upstream, whether Debian and/or X.Org, and then synch'ed into Ubuntu, not the reverse. Hence, Won't Fix Wishlist is the appropriate Status and Importance respectively. For more on this, please see:
https://wiki.ubuntu.com/Bugs/Status
https://wiki.ubuntu.com/Bugs/Importance

[Julien Cristau (jcristau)]

On Tue, Apr 1, 2014 at 10:59:49 -0000, Christopher M. Penalver wrote:

> Ralph Corderoy, as this is requesting a fundamental change as per the Bug Description, the fix would want to come from upstream, whether Debian and/or X.Org, and then synch'ed into Ubuntu, not the reverse. Hence, Won't Fix Wishlist is the appropriate Status and Importance respectively. For more on this, please see:
> https://wiki.ubuntu.com/Bugs/Status
> https://wiki.ubuntu.com/Bugs/Importance
>
The above is wrong. This is about a Debian-specific file, not something
inherited from upstream.

[penalvch (penalvch)]

Julien Cristau, Debian in this case would be Ubuntu's upstream. Are you suggesting Ubuntu deviate from Debian's bits here in this case?

[Julien Cristau (jcristau)]

On Wed, Apr 2, 2014 at 10:32:23 -0000, Christopher M. Penalver wrote:

> Julien Cristau, Debian in this case would be Ubuntu's upstream. Are you
> suggesting Ubuntu deviate from Debian's bits here in this case?
>
I'm suggesting if there's something to fix you fix it and send the fix
on upstream.

[Alberto Salvia Novella (es20490446e)]

This is a technical decision concerning Debian itself, and Ubuntu cannot decide on that. Sorry.