team-xbmc team mailing list archive

[Andres Mejia <amejia004@xxxxxxxxx>]

Hi all,
I just reported a bug with some of my concerns about xbmc-live. See [1].

I think xbmc-live needs to use less of the maintainer script to do
what it needs to do. I'll just repeat what I wrote in the bug report.

  * The script reads /etc/default/xbmc-live but no such file is installed.
    Whatever resides in /etc/default/ is meant for the sysv init scripts
    anyway so the line reading /etc/default/xbmc-live should be dropped.
  * Line changing allowed_users in Xwrapper.config. Is this line really
    necessary? I don't believe it's a good idea to allow all users to
    start X. Besides, it's poor practice for a package to override
    local administrator settings such as any settings in /etc.
  * Choosing an account to use with xbmc-live. I believe it would be
    better to simply choose an account to be used with xbmc-live
    (i.e. just choose 'xbmc'). This would help in installation of
    configuration files as then we could ship any needed config files
    in the xbmc-live package and not have to generate them with the
    maintainer scripts. Shipping the config files this way also ensures
    that any modifications done by the local administrator are not
    overridden after each update of xbmc-live. Choosing a dedicated
    account for xbmc will also remove the need to override the group
    settings for any preexisting user account.
  * Allow users to override password for dedicated xbmc-live account.
    It would be a good idea if users can override the default password
    used for the dedicated account. debconf can be used in this case.
  * sudoers config file.
    Maybe something else can be done that allows the xbmc-live account
    to shutdown, reboot, mount, and unmount drives in the system. Also,
    /etc/sudoers.d should be utilized for the xbmc specific sudo
    configuration.
  * grub modifications
    Modifications to grub need to be supplied in /etc/grub.d. It's generally
    not a good idea to override settings set by the local administrator.
  * Seperate xbmc-live package for different init systems.
    The xbmc-live package supplies scripts for both sysv init and upstart.
    The sysv and upstart packages are not coinstallable so the xbmc-live
    package should be split up.

Also, something else was mentioned about the creation of an xbmc-live
account. It's mentioned at [2] and I will repeated below.
"...Oh, and while we are it, please create a system user with its home
in /var/lib."

Here's a note about system users from the 'adduser' manpage.
   Add a system user
       If  called with one non-option argument and the --system
option, adduser will add a
       system user. If a user with the same name already exists in the
 system  uid  range
       (or, if the uid is specified, if a user with that uid already
exists), adduser will
       exit with a warning. This warning can be suppressed by adding "--quiet".

       adduser will choose the first available UID from the  range
specified  for  system
       users in the configuration file (FIRST_SYSTEM_UID and
LAST_SYSTEM_UID). If you want
       to have a specific UID, you can specify it using the --uid option.

       By default, system users are placed in the nogroup group.  To
place the new  system
       user  in  an  already existing group, use the --gid or
--ingroup options.  To place
       the new system user in a new group with the same ID, use the
--group option.

       A home directory is created by the same rules as for normal
users.  The new  system
       user  will  have  the shell /bin/false (unless overridden with
the --shell option),
       and have logins disabled.  Skeletal configuration files are not copied.

So basically, if we add a system user for xbmc-live, the --group
option will be needed, and the new user will have no shell and logins
disabled. Is this something we want?

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671275
2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669727

-- 
~ Andres