Re: possible bugs in xfs-related packages
On 23/11/99 Henrique M Holschuh wrote:
I don't really know. xfs-xtt shouldn't need to touch that file when it
receives a SIGUSR1, so why would it die? Now, I don't know about the socket
stuff in /tmp, but something else might be amiss here. That's why I filled
this as a separate bug.
I am not sure here, i am not as familier with xfs-xtt but it appears
to be pretty close to xfs and xfstt. they all keep sockets in
/tmp/.font-unix/ and for some reason they are usually mode 777
I do know my old xfs-xtt (Xfree86's xfs v.3.3.1 + X-TT patch 1.3) accepted
these signals happly, and it was run in a non priviledged uid.
I am running xfs plain on my old redhat box, as user xfs with no problems.
> this would be solved by the subdirectory in /var/run that xfs can
> write to its pid.
But the sockets would still be uid nobody, and thus to crash someone's
xserver you only need to break nobody and trash them. This is most certainly
Not a Good Thing.
no I want the xfses running as user xfs NOT as nobody, anything that
creates a file anywhere should not be run as nobody.
> and further to this, xfs should not be run as nobody, I do not think
> anything that writes to files anywhere should be running as nobody
> but rather its own user (please see recent archives on this)
I agree. The xfs man page actually warns against using -user...
it says that the user part is not well tested and not to run it as
nobody and instead give it its own uid.
I think we should not use -user since it remains running as root till
someone connects to it. we should use start-stop-daemon -chuid
xfs:xfs or sudo -u xfs xfs
> xfs user defined in debian for this use. (Wichert I think your
> maintainer of base-passwd, comments?)
That would fix things, and overall improve security, I think. Especially
since attacking xfs results easily in XFree86 crashes, so we're talking
about really easy-to-do DoS here once something running as nobody is
subverted. Heck, you just need to kill -HUP <xfs-xtt pid> as nobody to
manage it right now...
it would improve security we already have one running as root another
running as root half the time and nobody sometimes, both are wrong.
This is broken Xserver behaviour, of course, and I already filled a bug
against xserver-common, #51086.
This means we either run xfs as root (BAD) or as its own user until Xfree86
learns to cope better with font servers, or we risk a xserver segfault :^(
it should NEVER be run as nobody since that requires files to be
owned by nobody.
It's up to the base-passwd, xfs, xfstt and xfs-xtt maintainers now, I think.
the xfs-xtt maintainer is willing if the base-passwd allocates a
user, i think the others will follow as well.
> also I think that there should be no files anywhere owned by nobody
> and currently that is required because the xfs's run as nobody.
Hmm...
# find -user nobody
./var/tmp/.font-unix
./var/tmp/.font-unix/fs7100
yup
and of course the proc entries for processes running as nobody.
So, the only package being nasty in my system by having files owned by
nobody is xfs-xtt.
that is correct, and its wrong IMNSHO.
(if debian won't fix it I will maintain my own versions of these
packages that do, but that would be a pain and only benefit me, it
would be far better to fix it in debian and benefit all)
Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Reply to: