Re: cannot log in with gdm after lenny upgrade
On Thu, Jan 03, 2008 at 02:57:20AM +0000, Hendrik Boom <hendrik@topoi.pooq.com> was heard to say:
> On Wed, 02 Jan 2008 07:57:22 -0800, Daniel Burrows wrote:
> > On Wed, Jan 02, 2008 at 12:58:22AM +0000, Hendrik Boom <hendrik@topoi.pooq.com> was heard to say:
> >> Thanks. How did you ever manage to think of this?
> >
> > The main thing for me was to ignore all those messages about suid GTK+
> > programs; since the log continues past those messages, it's a good
> > (although not certain) bet that they're unrelated to the problem. Once
> > I read past them I saw the failures above (listen and mkdtemp),
> > which sound like a program trying to create a listen socket in /tmp and
> > failing.
> >
> > In particular, there's no other obvious reason for mkdtemp to fail
> > with "permission denied"; even "nobody" can write to /tmp on a default
> > Debian system. As Andrew said, that message is a pretty big clue, once
> > you've waded through all the other chatter in the log.
>
> I'm trying to understand how these library calls are related to /tmp,
> since this is the kind of stuff I think I should know about.
I'm glad to hear you were actually interested, I was a little worried
I might be replying to a rhetorical question. :-)
> I looked for the specification of listen(), and found a man page with the
> synopsis
> int listen(int socket, int backlog);
> No reference to /tmp here. And for mkdtemp I find
> char *mkdtemp(char *template);
> Could it be the template starts with "/tmp/XXXXXX" or something like that?
> Or are temporary directory is alwayse put inside /tmp ?
> How is a temporary directory related to a socket?
mkdtemp() is for creating temporary directories, which traditionally
go in /tmp. Most programs will check $TMPDIR and default to /tmp if
it's not set.
A number of popular desktop IPC packages use Unix-domain sockets or
named pipes created in /tmp. I'm particularly thinking of dbus, mcop (?),
and. Unix-domain sockets are sockets for communication between
processes on the same computer; they can appear in the filesystem (see
unix(7), socket(2) and bind(2) for more information on them) and are
subject to filesystem permission rules. They can also be created in an
"abstract namespace" which is not tied to the filesystem, and apparently
at least dbus does this. In that case permissions problems would not
affect them.
It's possible that the listen() failure was a red herring and I was
just lucky. ;-) It looks like dbus and friends create their sockets in
the abstract namespace, so the /tmp thing wouldn't affect them. (you
can use "find /tmp -type s" to find sockets in /tmp)
Daniel
Reply to: