•  
      request #7763 tuleap package : wrong chcon statement in postinstall scriptlet
    Infos
    #7763
    Martin Hamant (martin-h)
    2015-04-14 15:50
    2015-01-14 12:10
    7764
    Details
    tuleap package : wrong chcon statement in postinstall scriptlet
    Hi,

    As I haven't received any anwer on my post https://tuleap.net/plugins/forumml/message.php?group_id=101&topic=31733&list=1 , I want to add my two cents so this issue is solved once for all :)

    Here is the statement as it appears in the current package:
    # In any cases fix the context
    /usr/bin/chcon -R root:object_r:httpd_sys_content_t $RPM_BUILD_ROOT//usr/share/tuleap || true

    First, the correct* chcon statement is :
    /usr/bin/chcon -R -t httpd_sys_content_t /usr/share/tuleap
    OR
    /usr/bin/chcon -R -h root:object_r:httpd_sys_content_t:s0 /usr/share/tuleap
    * I suggest using the first one.

    Second, changes being made with chcon don't survive filesystem relabel. So, I would suggest to add :

    semanage fcontext -a -t httpd_sys_content_t '/usr/share/tuleap(/.*)?'

    The command above adds an entry to /etc/selinux/targeted/contexts/files/file_contexts.local, so the context of the folder is reset correctly when the filesystem is relabeled (for example with the use of 'restorecon').

    If you look at /usr/share/tuleap/tools/setup.sh you'll see the /usr/share/tuleap folder is handled with correct chcon statements so this should be the same in tuleap RPMs scriptlet.
    Installation process
    Empty
    CentOS 6
    • [ ] enhancement
    • [ ] internal improvement
    Thomas Cottier (tcottier), Thomas Gerbet (tgerbet)
    Stage
    Empty
    Closed
    2015-04-14
    Attachments
    Empty
    References

    Follow-ups

    User avatar
    Thomas Gerbet (tgerbet)2015-04-14 15:37
    No, the user enalean_packages is left untouched, the message is just here to warn you.
    User avatar
    Ok fine.

    Did it changed something for this user or his fiels (context?) or is just a warning ?
    User avatar
    Thomas Gerbet (tgerbet)2015-04-14 14:16
    According to the knowledgebase of Red Hat it appears to be normal when you have an user which has already a security context defined, a home directory in a non-default location or a shell different than /bin/false or /sbin/nologin.

    For the others users the context will be applied correctly despite the error message.

    https://access.redhat.com/solutions/44182
    User avatar

    After update I got

    enalean_packages homedir /var/lib/enalean_packages or its parent directory conflicts with a
    defined context in /etc/selinux/targeted/contexts/files/file_contexts,
    /usr/sbin/genhomedircon will not create a new context. This usually indicates an incorrectly defined system account.  If it is a system account please make sure its login shell is /sbin/nologin.

     


    • Status changed from Closed to Reopen
    • Close date cleared
    User avatar
    Merged in 8.0.99.27

    • Status changed from Under review to Closed
    • Close date set to 2015-04-13
    User avatar
    Thomas, that could be a stupid question but, isn't RPMs files built against those proposed patches within a CI environment for testing purpose ?
    User avatar
    Thomas Gerbet (tgerbet)2015-02-18 12:17
    Hello,
    If you want to test it, you can download the gerrit patch and build the RPMs from the SPEC files.
    As soon a patch is merged, it will be available with the next release.
    User avatar
    Thanks Thomas, what is the process for testing ? Can I do something ? How do we know the target Tuleap release version for the patch ? (or any patch in gerrit in fact)
    User avatar
    Thomas Gerbet (tgerbet)2015-02-05 17:02
    There is a patch under review for this: gerrit #3536. It is a first step in the right direction with SELinux: no more errors when SELinux is available and permissions are applied correctly.
    User avatar
    Thomas'ss could you have a look and do the corresponding patch if relevant ?

    • CC list set to Thomas Gerbet (tgerbet), Thomas Cottier (tcottier)
    User avatar
    Hi Manuel

    Bear in mind that I'm not a SELinux guru - I just got into the documentation and experiments.

    The first form change only the type, when the second change the whole context.

    I suggest using the first one because according to the documentation changing the type is generally enough for files. See this doc at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html :
    "Type Enforcement is the main permission control used in SELinux targeted policy. For the most part, SELinux users and roles can be ignored. "

    As a side note, '-h' option tells chcon to apply the context to symlinks too. This is may not be required in the given example.

    file context rules are not compiled what soever. There are stored in /etc/selinux/targeted/contexts/files/file_contexts which file is owned by selinux-policy-targeted package. A file is provided for local custom rules /etc/selinux/targeted/contexts/files/file_contexts.local (which is altered by semanage).

    In the case of Tuleap, we want apache to have access to those files, so we only need to change those files type.
    In the most common cases, writing an compiling a custom policy module is not needed (as there is also a possibility to use boolean...)

    However if we wanted a given process to access a given unix socket, we would have needed to write a custom policy module (like I did for nscd by the way...)

    http://wiki.centos.org/HowTos/SELinux is a good starting point for SELinux
    User avatar
    Could you explain why one form is better than another (for the first part) ?

    Second, as far as I understand, SELinux rules are meant to be bundled and compiled (at least it was the case early on RHEL5), is the semanage thing the new way or an alternate of something completely different ?