http://bugzilla.novell.com/show_bug.cgi?id=542051 Summary: xfs font server is poorly installed; standard security risk of using nobody Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Minor Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-UTF-8; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Found a couple of problems (none making xfs non functional, BTW), concerning the xfs font server that wouldn't be difficult to address and would improve security, fix-a-log-typo, and might easily make it more robust in the long term. 1) the startup script doesn't use any sysconfig file for parameters -- they are hard-coded. Arguments, ideally, should be in 'variables' in sysconfig. (I think of this of the equivalent of using numbers in programing vs. defined constants...generally not a great idea). 2) consistancy w/man page on how daemon runs: daemon man page (xfs(1)), says that if xfs is given the '-droppriv' argument, it will drop it's privs and try to run as "user.group" = "xfs.xfs'. Why shouldn't it do that by default? Instead, someone put it in the global user&group 'nobody' (now considered a common security vulnerability when multiple daemons all run in the same user and group). The install package should create the group: groupadd -r xfs and the user and group, preferring uid=gid (reasoning is multi-variate and too much to go into here, but it's of low pain/difficulty, raises security and can make life simpler later on -- especially if _all_ services install like this...). useradd --preferred-uid=$(grep /etc/group|cut -f3 -d: ) -r -g xfs xfs (or if you want to just try it and give an error on fail:) useradd -uid=$(grep /etc/group|cut -f3 -d: ) -r -g xfs xfs (depending on the 'collision', the "-o" switch might be accpetable -- i.e. if it is another service, unlikely to create any cross-chatter with xfs...but generally might be better to move "xfs's" group to a clear location). Now the rcscript shouldn't have to remove /tmp/.font-server and recreate it. Instead, it should (to be safe), check permissions -- if owned by xfs.xfs, then it _could_ check permissions to see it's not writeable by 'other' (but that can be a setting in /etc/permissions). If it does exist, to be safe, it should rename it to ".fontserver.user.group.mtime" (whatever user/group owns it with it's last mod-time. That should avoid any dangerous collisions and avoid potential data loss -- not to mention NOT, disturbing, any user-run 'xfs' font-server already running (if xfs uses relative pathnames after 'cd'ing to it's "home dir").). Wouldn't work windows, but we aren't on windows...:-). 3rd issue: a 'clarity issue') Even though parts of the X literature refer to it as the 'font server', the choice of "/var/log/fs-errors" seems poor. perhaps "xfs-errors", or better, "XFontServ-errors" (or more easily discernable as what the log belongs to). 'fs-errors' looks like file system, and xfs could be the xfs-file system... Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.