Possible /tmp/.ICE-unix

Kelledin 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.
> */
>
> And
>
> 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
> thread.

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 
underlying problem.

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 
anything.

The only currently viable solution I see is to create and chmod 
the directory correctly during system boot, preferably before X 
gets started.

-- 
Kelledin
"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 mailing list