kelledin+BLFS at skarpsey.dyndns.org
Sat May 17 22:29:10 PDT 2003
On Wednesday 30 April 2003 11:25 pm, Timothy Bauscher wrote:
> In xc/lib/xtrans/Xtransutil.c
> #ifdef HAS_FCHOWN
> * If fchown(2) and fchmod(2) are available, try to correct the
> * directory's owner and mode. Otherwise it isn't safe to
> attempt * to do this.
> if (updateOwner && fchown(fd, 0, 0) == 0)
> updatedOwner = 1;
> From chown(2):
> int fchown(int fd, uid_t owner, gid_t group);
> Perhaps if HAS_FCHOWN is defined this problem will go away.
> Can someone test this? My x11 configuration doesn't even
> create that directory.
> Or maybe this "solution" has already been brought up. In that
> case, please excuse my ignorance, I didn't read the whole
Well...I finally got around to investigating it, and I decided
I'd revive the issue, at least to clarify the situation.
1) /tmp/.ICE-unix _ought_ to be created 01777 and handed over to
root:root ownership. Anything else grants an unprivileged user
the power to delete other users' ICE socket files. This isn't
such a big problem for a single-user workstation, but it's a
security hazard for stations with multiuser X logins.
2) The reason why it's _not_ getting ownership handed over to
root:root is because fchmod() is failing when called. fchmod()
is failing because normally /tmp/.ICE-unix is created by an
unprivileged user pretty late in the login session.
Unprivileged users can't successfully call fchown(), for fairly
obvious reasons. Damn. :(
3) This causes a pause because KDE (and some versions of X) will
insert a 5-second sleep if they can't set the permissions on
/tmp/.ICE-unix correctly. We could probably take out this
five-second sleep easily, but it doesn't solve the real
At this point, the problem is really a fundamental flaw in the
way X handles sessions started by unprivileged users. Fixing it
is a nontrivial affair, and fixing it the Wrong Way could
introduce serious security holes. I have a few ideas, but I'm
going to consult the XFree86 developers before I recommend
The only currently viable solution I see is to create and chmod
the directory correctly during system boot, preferably before X
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message
More information about the blfs-dev