[Fwd: games user and group]

Michael Thomas wart at kobold.org
Wed Mar 1 17:11:52 UTC 2006


Bill Nottingham wrote:
> Michael Thomas (wart at kobold.org) said: 
> 
>>Daemon processes
>>================
>>Some games such as wesnoth and xpilot-ng come with server daemons.  I
>>see three choices for the owner of these daemon processes:
>>
>>1) root (ick!)
>>2) Allocate a separate '<gamename>' user for each package/daemon
>>3) Piggyback on the 'games' user
>>
>>My preference would be #3.  Are there any drawbacks to reusing the
>>'games' user to run various game daemons?
> 
> 
> Someone who compromises one game server could compromise
> any other servers running under the same user, etc.

I see your point.  I figured that the nature of games made them less
important with respect to this type of security risk.  Reusing the games
user also makes the user management issues with the packaging much
simpler (no fedora-useradd registration or dynamic userid with useradd).

There's also the option of using selinux policies to make things more
secure.  This should probably be done regardless of whether the daemons
run under a single userid or separate ones.

>>File ownership
>>==============
>>Almost every package that I see in FE uses %defattr(-,root,root,-).  Is
>>there any reason why we shouldn't be using %defattr(-,games,games,-) for
>>game packages (including documentation, manpages and such)?
> 
> 
> There's no reason to really have the files owned by the games user;
> in fact, it's probably more secure to leave them owned by root, and
> just leave the scorefiles owned by games.

Fair enough.  Some of the executables will still have to be setgid
'games' to that users can write to the shared scoreboard file.  I don't
think it would be reasonable to tell admins that they have to add users
to the 'games' group just for this purpose, especially when there might
be many users.

--Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060301/e9df50b2/attachment.bin>


More information about the fedora-extras-list mailing list