Bug 9234 - xfs -port -1 failure
Summary: xfs -port -1 failure
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 6.1
Hardware: i386 Linux
medium
high
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-08 18:18 UTC by rdt
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-30 18:46:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description rdt 2000-02-08 18:18:26 UTC
xfs -port -1 produces

_FontTransSocketINETCreateListener: Unable to get service for -1
_FontTransMakeAllCOTSServerListeners: failed to create listener for tcp

On the other hand, xfs -port 7100 works fine, and I can then do
xset +fp tcp/localhost:7100 as usual. I reported this on redhat-devel
and someone responded that they had had exactly the same problem
with no resolution.

Comment 1 rdt 2000-02-09 12:04:59 UTC
The options -droppriv -daemon used in the init.d/xfs script seem to have some
effect on this:  xfs -droppriv -daemon -port -1 doesn't work, but
xfs -daemon -port -1 *does*.  Are these options documented anywhere?

Comment 2 Preston Brown 2000-02-10 20:11:59 UTC
these will be documented in XFree86-3.3.6-12 and later.

Comment 3 rdt 2000-02-10 20:32:59 UTC
So how does telling us about vapourware documentation "resolve"
the problem?  I don't know how to start xfs safely.  Either
I use a tcp port, opening a security hole, or I seem to have
to not drop root privileges.  The xfs script in init.d doesn't
work on my system.

Comment 4 snikhi1 2000-03-10 13:44:59 UTC
I run RH 6.1. After updating several new packages from the Errata page xfs
stopped working (it wouldn't startup) for me too except if I remove -droppriv
option from xfs startup script (that is now: daemon xfs -daemon -port -1,
instead of daemon xfs -droppriv -daemon -port -1). However in that case xfs
starts and stays as root which is a security hole, and should not be like this.
I updated only these packages to the latest versions available from the Errata:

lpr-0.48-1.i386.rpm
pam-0.68-10.i386.rpm
usermode-1.18-1.i386.rpm
sharutils-4.2.1-1.6.1.i386.rpm
groff-1.15-1.i386.rpm
groff-gxditview-1.15-1.i386.rpm
libtiff-3.5.4-1.i386.rpm
libtiff-devel-3.5.4-1.i386.rpm

Now, I am not sure how these packages may affect xfs, but the fact is that
before the update everything worked fine. So, since now there is a security
hole, I would ask you please to fix this as soon as possible.
Thanks.

Comment 5 Anonymous 2000-04-25 13:35:59 UTC
I have the same problem. The only difference is that it happened after I rebuilt
the kernel to increase IPC resources. Now, xfs fails with both kernels unless I
delete the droppriv option from xfs invocation. xfs and its configuration file
have not been changed due to kernel rebuild. Why does kernel build affect xfs
functionality?

Also, the same problem reported back in 6.0 with bug 4540.

Comment 6 Preston Brown 2000-05-30 18:46:59 UTC
what error does xfs report when started with -droppriv?  It should be reporting
some sort of error if there is a problem.

We can't duplicate this here.  If someone can provide an strace of the situation
or some error output, it would help a lot.

Comment 7 rdt 2000-05-31 12:44:30 UTC
The problem was caused on my box by a fonts.dir file that wasn't world readable.
Thanks to Preston Brown, who figured it out from an strace -f.


Note You need to log in before you can comment on or make changes to this bug.