#569 UNICORE directory permission settings of debian/rpm

UNICORE6.6
closed-fixed
UNICORE/X (78)
5
2012-12-05
2012-08-03
Mathilde
No

after Debian install of the UNICORE packages the setting of ownership access permissions keeps components from starting:
/var/log/unicore directory belongs to root with rwx, components cannot create their log files in /var/log/unicore/<component> as they are started with a non-root unserid

/var/lib/unicore/unicorex directory belongs to root with rwx, so the non-root userid cannot write into it (Error setting up persistence .... permission denied)

related GGUS ticket: https://ggus.eu/tech/ticket_show.php?ticket=83342

Discussion

  • Mathilde
    Mathilde
    2012-08-03

    in addition owner and permission setting for the UNICORE component directories and files are inconsistent:

    /usr/sbin:
    -rwxr-xr-x 1 root root 681 May 18 14:41 unicore-gateway-start.sh
    -rwxr-xr-x 1 root root 455 May 18 14:41 unicore-gateway-stop.sh
    -rwxr-xr-x 1 root root 2131 May 18 14:23 unicore-registry-start.sh
    -rwxr-xr-x 1 root root 911 May 18 14:23 unicore-registry-status.sh
    -rwxr-xr-x 1 root root 796 May 18 14:23 unicore-registry-stop.sh
    -rwxr-xr-x 1 unicore unicore 773 May 18 15:34 unicore-unicorex-start.sh
    -rwxr-xr-x 1 unicore unicore 559 May 18 15:34 unicore-unicorex-status.sh
    -rwxr-xr-x 1 unicore unicore 475 May 18 15:34 unicore-unicorex-stop.sh
    -rwxr-xr-x 1 root root 1195 May 18 15:22 unicore-xuudb-admin
    -rwxr-xr-x 1 root root 1243 May 18 15:22 unicore-xuudb-start
    -rwxr-xr-x 1 root root 433 May 18 15:22 unicore-xuudb-stop

    /etc/init.d
    -rwxr-xr-x 1 root root 1385 May 18 14:41 unicore-gateway
    -rwxr-xr-x 1 root root 1576 May 18 14:23 unicore-registry
    -rwxr-xr-x 1 root root 1793 May 18 15:46 unicore-tsi
    -rwxr-xr-x 1 unicore unicore 1577 May 18 15:34 unicore-unicorex
    -rwxr-xr-x 1 root root 1472 May 18 15:22 unicore-xuudb

    /var/log/unicore
    265260 4 drwxr-xr-x 6 root root 4096 Jun 12 16:59 .
    265261 4 drwxr-xr-x 2 unicore unicore 4096 Jun 13 14:07 gateway
    265369 4 drwxr-xr-x 2 unicore unicore 4096 Jun 15 16:46 registry
    265803 4 drwx------ 2 unicore unicore 4096 Jun 15 15:52 unicorex
    265849 4 drwxr-xr-x 2 unicore unicore 4096 Jun 15 10:03 xuudb

    /etc/unicore
    137850 4 drwxr-xr-x 7 root root 4096 Jun 18 09:21 .
    137851 4 drwxr-xr-x 2 root root 4096 Jun 15 16:35 gateway
    265263 4 drwxr-x--- 3 unicore unicore 4096 Jun 15 16:46 registry
    265489 4 drwxr-xr-x 2 root root 4096 Jun 12 17:00 ucc
    265615 4 drwxr-xr-x 3 unicore unicore 4096 Jun 15 16:43 unicorex
    265804 4 drwxr-xr-x 2 unicore unicore 4096 Jun 15 10:15 xuudb

     
  • Strange - it seems that in the source everything is correct. Investigating...

     
    • assigned_to: bschuller --> ppiernik
    • status: open --> open-accepted
     
  • Regarding the inconsistency - this is rather for unicore/x, or do you consider it a bug in XUUDB (and all others which share the same convention as XUUDB)?

     
  • Mathilde
    Mathilde
    2012-08-03

    for the inconsistency: yes you can say it is primarily the unicorex (regisatry has a different setting in /etc/unicore) but you could also see it the way that all components except for unicorex have wrong ownership - shouldn't they all belong to user unicore?

     
  • Hello,
    the same inconsistency refers to RPM packages (tested EMI-2 SL5 repo).

    First of all, I want to apologise for long comment, but I was not able to enclose an attachment with listings as a separate file (I'm not owner of a ticket). So now they are together with my comments inlined organized in the same order as in initial comment (+ one problem during installation using yum).

    0.) Installing packages from EMI-2 repo

    # yum install unicore-gateway6 unicore-registry6 unicore-tsi6 unicore-ucc6 unicore-unicorex6 unicore-uvos-server unicore-xuudb

    [...]
    Running Transaction
    Installing : unicore-tsi6 1/7
    Installing : unicore-gateway6 2/7
    Installing : unicore-ucc6 3/7
    Installing : unicore-xuudb 4/7
    Installing : unicore-registry6 5/7
    warning: group mockbuild does not exist - using root
    warning: group mockbuild does not exist - using root
    warning: group mockbuild does not exist - using root
    warning: group mockbuild does not exist - using root
    Installing : unicore-uvos-server 6/7
    Installing : unicore-unicorex6 7/7

    Installed:
    unicore-gateway6.noarch 0:4.3.0-2.sl5 unicore-registry6.noarch 0:5.0.0-0.sl5
    unicore-tsi6.noarch 0:5.0.0-0.sl5 unicore-ucc6.noarch 0:5.0.0-1.sl5
    unicore-unicorex6.noarch 0:5.0.0-0.sl5 unicore-uvos-server.noarch 0:1.5.1-0.sl5
    unicore-xuudb.noarch 0:1.3.2-4.sl5

    Complete!

    Problem:
    -) during installation of unicore-registry6 there are 4 disturbing warnings:
    "warning: group mockbuild does not exist - using root"
    (maybe wrong group definition in spec file)

    1.) UNICORE managing scripts

    # ls -al /usr/sbin/unicore-*

    -rwxr-xr-x 1 root root 681 May 17 07:00 /usr/sbin/unicore-gateway-start.sh
    -rwxr-xr-x 1 root root 455 May 17 07:00 /usr/sbin/unicore-gateway-stop.sh
    -rwxr-xr-x 1 nobody root 2131 May 17 04:42 /usr/sbin/unicore-registry-start.sh
    -rwxr-xr-x 1 nobody root 911 May 17 04:42 /usr/sbin/unicore-registry-status.sh
    -rwxr-xr-x 1 nobody root 796 May 17 04:42 /usr/sbin/unicore-registry-stop.sh
    -rwxr-xr-x 1 unicore unicore 773 May 17 04:24 /usr/sbin/unicore-unicorex-start.sh
    -rwxr-xr-x 1 unicore unicore 559 May 17 04:24 /usr/sbin/unicore-unicorex-status.sh
    -rwxr-xr-x 1 unicore unicore 475 May 17 04:24 /usr/sbin/unicore-unicorex-stop.sh
    -rwxr-xr-x 1 root root 213 May 17 07:08 /usr/sbin/unicore-uvos-server-convertLDAPSchema
    -rwxr-xr-x 1 root root 223 May 17 07:08 /usr/sbin/unicore-uvos-server-createExampleContent
    -rwxr-xr-x 1 root root 254 May 17 07:08 /usr/sbin/unicore-uvos-server-initdb
    -rwxr-xr-x 1 root root 936 May 17 07:08 /usr/sbin/unicore-uvos-server-start
    -rwxr-xr-x 1 root root 502 May 17 07:08 /usr/sbin/unicore-uvos-server-stop
    -rwxr-xr-x 1 root root 193 May 17 07:08 /usr/sbin/unicore-uvos-server-updateDbVersion
    -rwxr-xr-x 1 root root 1195 May 17 01:21 /usr/sbin/unicore-xuudb-admin
    -rwxr-xr-x 1 root root 1243 May 17 01:21 /usr/sbin/unicore-xuudb-start
    -rwxr-xr-x 1 root root 433 May 17 01:21 /usr/sbin/unicore-xuudb-stop

    Inconsistency:
    -) scripts for registry are owned by nobody:root
    -) scripts for unicorex are owned by unicore:unicore
    -) other scripts are owned by root:root

    I think that here, all scripts should be own by root:root.
    All permissions are OK.

    2.) System controlling scripts

    # ls -al /etc/init.d/unicore-*

    -rwxr-xr-x 1 root root 1064 May 17 07:00 /etc/init.d/unicore-gateway
    -rwxr-xr-x 1 nobody root 1005 May 17 04:42 /etc/init.d/unicore-registry
    -rwxr--r-- 1 root root 1024 May 7 16:56 /etc/init.d/unicore-tsi
    -rwxr-xr-x 1 unicore unicore 1009 May 17 04:24 /etc/init.d/unicore-unicorex
    -rwxr-xr-x 1 root root 1028 May 17 07:08 /etc/init.d/unicore-uvos-server
    -rwxr-xr-x 1 root root 890 May 17 01:21 /etc/init.d/unicore-xuudb

    The same situation like in 1.:
    -) /etc/init.d/unicore-registry owned by nobody:root
    -) /etc/init.d/unicore-unicorex owned by unicore:unicore

    All UNICORE init.d scripts could be owned by root:root, I think.
    There is also different permission of unicore-tsi script.

    3.) Log directories

    # ls -al /var/log/unicore/

    total 32
    drwx------ 7 root root 4096 Aug 3 17:01 .
    drwxr-xr-x 15 root root 4096 Aug 3 17:01 ..
    drwxr-xr-x 2 unicore unicore 4096 May 17 07:00 gateway
    drwx------ 2 unicore unicore 4096 May 17 04:42 registry
    drwxr-xr-x 2 unicore unicore 4096 May 17 04:24 unicorex
    drwxr-xr-x 2 unicore unicore 4096 May 17 07:08 uvos-server
    drwxr-xr-x 2 unicore unicore 4096 May 17 01:21 xuudb

    First of all - strange, but it can be seen that directory /var/log/unicore is owned by root:root with permission 'drwx------'. Services running as unicore user can't write logs in that situation.

    Maybe it would help to add %dir directive specific for this directory in SPEC file for every components.

    Another issue are permissions for directories. I think, that those should not be readable for every users, but only with permissions 'drwxr-x---'.
    Nevertheless,
    to have consistent directory structure, it is enough to change permission of directory /var/log/unicore/registry to 'drwxr-xr-x'.

    4.) Configuration directories

    # ls -al /etc/unicore/

    total 48
    drwxr-xr-x 9 root root 4096 Aug 3 17:01 .
    drwxr-xr-x 107 root root 12288 Aug 3 17:01 ..
    drwxr-x--- 2 unicore unicore 4096 Aug 3 17:01 gateway
    drwxr-xr-x 3 root root 4096 Aug 3 17:01 registry
    drwxr-xr-x 2 root root 4096 Aug 3 17:01 tsi
    drwxr-xr-x 2 root root 4096 Aug 3 17:01 ucc
    drwxr-xr-x 3 unicore unicore 4096 Aug 3 17:01 unicorex
    drwxr-x--- 5 unicore unicore 4096 Aug 3 17:01 uvos-server
    drwxr-xr-x 2 unicore unicore 4096 Aug 3 17:01 xuudb

    My suggestions for changes here:
    -) /etc/unicore/registry owned by unicore:unicore with chmod 'drwxr-x---'
    -) /etc/unicore/unicorex with chmod 'drwxr-x---'
    -) /etc/unicore/xuudb with chmod 'drwxr-x---'

    Rest in my opinion is OK.

    Hope my it helps to investigate packages settings and to make them more consistent.

    Kind regards,
    Rafal Kluszczynski

     
  • Dear Mathilde and Rafal,

    Inconsistency per se need not to be a bug. In some cases there are reasons for different permissions, e.g. one /etc config file might be readable by all another, with passwords not.

    In case of binaries and scripts (/usr/sbin and /etc/init.d) you are right: there is a bug in registry and unicorex as those scripts should be owned by root. It is an obvious security vulnerability. This applies (though reasons are different) for Debian and SL. Correct perms are as in case of XUUDB scripts: root:root and 0755. I'll open a ticket for this.

    Regarding /var/log/unicore - there is no strong reason for having this owned by unicore, as all components should log to subdirectories of this directory and those subdirectories must be owned by unicore. However, if we ever change our minds it might be better to chown this directory to unicor too. However this is not something which anyhow affects a system. Also I can't see any reason for making those directories not world readable (of course if an administrator has any reasons she is free to chmod the directory).

    Regarding /etc/ I can't see any bug and you can't assume that there will be different permissions. However for consistency (so admins life is easier and they don't need to think in case by case basis) unicorex, ucc and registry folders can be made owned by unicore:unicore.

    Regarding the ticket itself we are still working on it.

     
    • assigned_to: ppiernik --> bschuller
    • labels: 643985 --> UNICORE/X
     
  • Dear Mathilde,

    can you please provide more details about the first part? Strictly speaking the ownership of /var/log/unicore is not a problem. But I suppose that one or another concrete package doesn't properly set the ownership of /var/log/unicore/component. Can you write for which component(s) you get this problem?

    Regarding the second part - it is right, Piotr verified that there is a problem in unicore/x debian configuration. Therefore reassigning to Bernd. We will fix this in the SVN.

     
  • Mathilde
    Mathilde
    2012-08-06

    Hi Krzysztof,

    the ownership of /var/log/unicore is a problem as with rwx for the owner only, none of the unicore services running as normal user are able to write into its /var/log/unicore/<unicoreservice> directory.
    Eiter the directory gets a chmod 755 or the owner of it is unicore.

     
  • Hi,
    just 2 remarks.

    On 2012-08-06 09:11, SourceForge.net wrote:
    > Regarding /var/log/unicore - there is no strong reason for having this
    > owned by unicore, as all components should log to subdirectories of this
    > directory and those subdirectories must be owned by unicore. However, if we
    > ever change our minds it might be better to chown this directory to unicor
    > too. However this is not something which anyhow affects a system.
    OK, I understand that there is no strong reason with permissions of subdirectories.

    But problem with /var/log/unicore exists, and for some reason (after example install I listed) it is set to to by only accessible by root:root (chmod "drwx------"). This can be seen in the listing I sent before. Maybe it would be good to set this directory always to 755 in spec files...

    > Regarding /etc/ I can't see any bug and you can't assume that there will be
    > different permissions. However for consistency (so admins life is easier
    > and they don't need to think in case by case basis) unicorex, ucc and
    > registry folders can be made owned by unicore:unicore.
    Yes, it would look better in case of unicorex and registry, but in case of ucc I would not change it to unicore user.
    This is a client and I think it should not be needed to have unicore user at client hosts (for example: gLite UI in PL-Grid). So this one I would leave as it is now.

    Kind regards,
    --
    Rafal Kluszczynski

     
  • Ah I see - so /var/log/unicore is rwx------. It was not clear as our installation made by Piotr had this correct, i.e. rwxr-xr-x.

    So the same question remains - it seems that one or another component messes up the permissions of this directory. Can you please provide an information what are the components installed on the problematic box?

     
  • Mathilde
    Mathilde
    2012-08-06

    Hi Krzysztof,

    as I mentioned in comment #1, the components are registry, gateway, unicorex, and xuudb:
    /var/log/unicore
    265260 4 drwx------ 6 root root 4096 Jun 12 16:59 .
    265261 4 drwxr-xr-x 2 unicore unicore 4096 Jun 13 14:07 gateway
    265369 4 drwxr-xr-x 2 unicore unicore 4096 Jun 15 16:46 registry
    265803 4 drwx------ 2 unicore unicore 4096 Jun 15 15:52 unicorex
    265849 4 drwxr-xr-x 2 unicore unicore 4096 Jun 15 10:03 xuudb

    With respect to consistency and security it might be better to have the ownership of the components with non-privileged userid unicore. Then you could stay with permissions 700 (rwx------) for all directories. No one could then access the files except for unicore and root and all data, especially sensitive information, is protected.

     
  • Bernd Schuller
    Bernd Schuller
    2012-12-05

    I checked SVN Trunk of UNICORE/X, Registry, Gateway and XUUDB and all have 755 and owner unicore for both deb and rpm. So I'm setting this to fixed. The 6.6.0 release (EMI-3) will have this. If we release 6.5.1 in EMI (which I'd prefer not to), I'll check it there too.

     
  • Bernd Schuller
    Bernd Schuller
    2012-12-05

    • milestone: 2902480 --> UNICORE6.6
    • status: open-accepted --> closed-fixed