Bug#276545: Xsession: $ERRFILE ($HOME/.xsession-errors) grows without bound
Branden Robinson writes: > severity 276545 wishlist > retitle 276545 xfree86-common: badly-behaved X clients fill > $HOME/.xsession-errors with crap, and this is your package's fault > tag 276545 + wontfix > thanks > > On Thu, Oct 14, 2004 at 03:13:48PM -0400, Jeff Sheinberg wrote: > > Package: xfree86-common > > Version: 4.3.0.dfsg.1-8 > > Severity: normal > > > > Hi, > > > > Since the last upgrade in sarge/testing, the $ERRFILE, nominally > > $HOME/.xsession-errors, grows without bound, since it is no longer > > being truncated. > > > > I believe that this change is a mistake, however, controlling this > > behavior via a setting in the "/etc/X11/Xsession.options" file is > > certainly accceptable to me. > > I'm not going to fix this for the reasons I outlined in a discussion[1] > with Chris Waters back in July. > > Quoting: > > For the time being, I do not agree. > > Justification #1: Xsession is a conffile and anybody who's annoyed by this > can apply your patch or a similar one themselves. > > Justification #2: I think programs and libraries -- especially GTK+ and Qt > and their dependent hordes -- need to be broken of the philosophy that > .xsession-errors is just another name for /dev/null. Anything that spews > gouts of garbage to the file needs a bug filed against it, and I strongly > encourage you to do so. > > I didn't get the memo that said .xsession-errors is supposed to be useless, > and I resent the Desktop Movement for trying to make it thus. > > [1] http://lists.debian.org/debian-x/2004/07/msg00068.html > > -- > G. Branden Robinson|Men use thought only to justify > Debian GNU/Linux |their wrong doings, and speech only > [EMAIL PROTECTED] |to conceal their thoughts. > http://people.debian.org/~branden/ |-- Voltaire Branden, I disagree with you here, because the original bug submission has nothing whatsoever to do with "badly-behaved X clients". I stand by my assertion that the $ERRFILE grows without bound, and therefore, it should probably be controlled by an option in the /etc/X11/Xsession.options file. Thanks, -- Jeff Sheinberg
Bug#276545: Xsession: $ERRFILE ($HOME/.xsession-errors) grows without bound
Package: xfree86-common Version: 4.3.0.dfsg.1-8 Severity: normal Hi, Since the last upgrade in sarge/testing, the $ERRFILE, nominally $HOME/.xsession-errors, grows without bound, since it is no longer being truncated. I believe that this change is a mistake, however, controlling this behavior via a setting in the "/etc/X11/Xsession.options" file is certainly accceptable to me. Thanks, -- Jeff Sheinberg -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.27-2 Locale: LANG=C, LC_CTYPE=C Versions of packages xfree86-common depends on: ii debconf 1.4.30.5 Debian configuration management sy ii debianutils 2.8.4 Miscellaneous utilities specific t -- debconf information: xfree86-common/experimental_packages:
Bug#118856: xbase-clients: xconsole: loses messages (possible buffer overrun?)
Branden Robinson writes: > On Fri, Nov 09, 2001 at 10:51:05AM -0500, Jeff Sheinberg wrote: > > I have noticed this strange output in the "xconsole" window > > whenever I boot up my computer, > > > > Nov 9 08:28:55 eden-hda7 Nov 9 08:28:55 eden-hda7 Nov 9 > > 08:28:55 Nov 9 09:52:31 eden-hda7 PAM_unix[793]: (login) session > > opened for user jsroot by jeff(uid=1001) > > > > ie, the three "Nov 9 08:28:55" entries at the end of the window. > > Yes, I've seen this behavior myself for as long as I've been using > xconsole on Linux, which has been a few years. I looked over the > xconsole code recently in conjuntion with a separate issue, but cannot > think of a reason why this may be happening. Hi Branden, I think I finally realize what is happening here, due to a kind person explaining to me (unfortunately, off list, and I have lost their email), regarding this bug against "syslog-ng", Bug#192054: syslog-ng: STATS: dropped 71 So, if you agree with my explanation, which follows, then please reassign this bug to the "sysklogd" package, which is the syslog deamon that I had installed when the bug was first reported. Basically, the problem is that the syslog daemon has to communicate the errlog messages to the xconsole program through a named pipe, but until xconsole is actually running, any writes to the named pipe will be rejected (via SIGPIPE signal and/or EPIPE error return) because the named pipe has not yet been opened for reading. Of course, the syslog deamon just ignores these errors, and buffers the rejected messages internally, but eventually, the syslog daemon's buffers will become full, resulting in lost/truncated messages eventually being delivered to xconsole when the named piped does become opened for reading. I think that the syslog daemon should handle a buffer full condition for a destination that is a pipe (perhaps any destination that is not a local file) in a way that the the oldest messages are deleted to make room for newer messages, rather than the other way around, as is currently being done. Thanks, -- Jeff Sheinberg
Re: a small C program to test xdm's /dev/mem reading on your architecture
Marcus Brinkmann writes:
> On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
> > > I can't believe he actually intends to keep it like this..
> >
> > I'm going to #define DEV_RANDOM /dev/random for Linux systems.
>
> That's bad, because that will drain the entropy a lot, and it might
> block for a long time, and that for no good reason as I don't think the
> magic cookie needs strong cryptographical security (for comparison: The
> secret key of a public key cryptography key pair should be created using
> /dev/random, while for session keys /dev/urandom is good enough).
Here is how I create the magic cookie in my ~/.xserverrc shell script,
cookie ()
{
dd if=/dev/urandom 2>/dev/null bs=16 count=1 | od -x | awk ' NR==1 {
print $2 $3 $4 $5 $6 $7 $8 $9 } '
}
e.g.,
$ cookie
a0de8e57919780bbc5ff16e66e1af2a9
and I use it in .xserverrc like this,
mcookie=`cookie`
# Add this cookie to the X server auth file.
xauth -f "${auth}" \
-v add "0.0.0.0:${xdpnum}" "${access}" "${mcookie}"
# Add necessary new display entries to .Xauthority file.
xauth -v add "${eth0}:${xdpnum}" "${access}" "${mcookie}"
xauth -v add "${host}:${xdpnum}" "${access}" "${mcookie}"
xauth -v add "${host}/unix:${xdpnum}" "${access}" "${mcookie}"
Why does anyone need to read megabytes of urandom? If it really
is random, then 16 bytes should be enough.
--
Jeff Sheinberg
Re: emacs to run as root from su, in its own X window?
Dan Jacobson writes: > The following message is a courtesy copy of an article > that has been posted to gnu.emacs.bug as well. > > This may be a debian specific problem, hence the CC. No. You need to understand how access control works in the X server. > > It may be "user lack of understanding". If so, "then beef up the > FAQs". Or maybe I didn't look. Anyways, I solved the problem. I put > xhost local:root #dangerous? else root can't open an emacs window > in ~/.xsession. Anyways, the problem was: > > How do I get emacs to run as root when I do su, in its own X window? > $ su > # emacs > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > emacs: Cannot connect to X server :0.0. > Check the DISPLAY environment variable or use `-d'. > Also use the `xhost' program to verify that it is set to permit > connections from your machine. > # xhost > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > xhost: unable to open display ":0.0" > # suspend > $ xhost local:root > non-network local connections being added to access control list > > OK, that fixed it. But gee, don't you see some silly actions above, > like root doing a local command that doesn't need a DISPLAY to get its > job done being denied, etc. Better be nice to root or he will remove you. Basically, you just need to copy the .Xauthority info for the display in question (from ~joeuser/.Xauthority to ~root/.Xauthority). You can't do this directly, you need to use the xauth program to do this for you. I assume that you use startx to start up the X server. If you instead enable xdm, then you can learn from it (/etc/X11/xdm/* how it uses the .Xauthority mechanism. Read the man page for xauth, and the X man page, section about access control, also the xdm man page. Eventually, it will dawn on you what is going on here. I would highly suggest that you read the book "X User Tools" published by O'Reilly, see especially page 430, Section 19.13 "Extending Access Control to Another User'. Then, after you have digested all of this, you will want to automate the mechanism you have been using manually. Hint - create a new group called "xlocal". Make all of those users that you want to be able to automatically share local access to the X server be members of the "xlocal" group. Next, you need to make your source (the user that started up the X server) user's .Xauthority file be readable by group "xlocal". The only catch here is that anytime xauth is run, it will change the perms on your .Xauthority file back to 600, so you need to change them back to 640 after you have run xauth. There are some other subtle details that need to be taken care of in order to create a clean implementation of the scheme that I have just suggested, you will discover them when something goes wrong! Eg, after you su to root, how does the root user know which user originally started up the X server, since it needs to be able to transfer the access records from that user's .Xauthority file? > > By the way, apt-cache show xbase-clients says >xhost, a very dangerous program that you should never use; > Well, the man page didn't warn me. So I used it. Will my system be > ruined now? > > By the way, on the xhost man page it says > FILES >/etc/X*.hosts > > But like hey, > ls: /etc/X*.hosts: No such file or directory > > So it's a mystery where it wrote whatever it wrote. The X server keeps the xhost specified status in its private data. > > P.S. oh, it probably didn't write anywhere, so I do the writing, in > .xsession. > -- > http://jidanni.org/ Taiwan(04)25854780 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Jeff Sheinberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: emacs to run as root from su, in its own X window?
Dan Jacobson writes: > The following message is a courtesy copy of an article > that has been posted to gnu.emacs.bug as well. > > This may be a debian specific problem, hence the CC. No. You need to understand how access control works in the X server. > > It may be "user lack of understanding". If so, "then beef up the > FAQs". Or maybe I didn't look. Anyways, I solved the problem. I put > xhost local:root #dangerous? else root can't open an emacs window > in ~/.xsession. Anyways, the problem was: > > How do I get emacs to run as root when I do su, in its own X window? > $ su > # emacs > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > emacs: Cannot connect to X server :0.0. > Check the DISPLAY environment variable or use `-d'. > Also use the `xhost' program to verify that it is set to permit > connections from your machine. > # xhost > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > xhost: unable to open display ":0.0" > # suspend > $ xhost local:root > non-network local connections being added to access control list > > OK, that fixed it. But gee, don't you see some silly actions above, > like root doing a local command that doesn't need a DISPLAY to get its > job done being denied, etc. Better be nice to root or he will remove you. Basically, you just need to copy the .Xauthority info for the display in question (from ~joeuser/.Xauthority to ~root/.Xauthority). You can't do this directly, you need to use the xauth program to do this for you. I assume that you use startx to start up the X server. If you instead enable xdm, then you can learn from it (/etc/X11/xdm/* how it uses the .Xauthority mechanism. Read the man page for xauth, and the X man page, section about access control, also the xdm man page. Eventually, it will dawn on you what is going on here. I would highly suggest that you read the book "X User Tools" published by O'Reilly, see especially page 430, Section 19.13 "Extending Access Control to Another User'. Then, after you have digested all of this, you will want to automate the mechanism you have been using manually. Hint - create a new group called "xlocal". Make all of those users that you want to be able to automatically share local access to the X server be members of the "xlocal" group. Next, you need to make your source (the user that started up the X server) user's .Xauthority file be readable by group "xlocal". The only catch here is that anytime xauth is run, it will change the perms on your .Xauthority file back to 600, so you need to change them back to 640 after you have run xauth. There are some other subtle details that need to be taken care of in order to create a clean implementation of the scheme that I have just suggested, you will discover them when something goes wrong! Eg, after you su to root, how does the root user know which user originally started up the X server, since it needs to be able to transfer the access records from that user's .Xauthority file? > > By the way, apt-cache show xbase-clients says >xhost, a very dangerous program that you should never use; > Well, the man page didn't warn me. So I used it. Will my system be > ruined now? > > By the way, on the xhost man page it says > FILES >/etc/X*.hosts > > But like hey, > ls: /etc/X*.hosts: No such file or directory > > So it's a mystery where it wrote whatever it wrote. The X server keeps the xhost specified status in its private data. > > P.S. oh, it probably didn't write anywhere, so I do the writing, in .xsession. > -- > http://jidanni.org/ Taiwan(04)25854780 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Jeff Sheinberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
