Petals Distribution

petals-cli and petals-registry-cli debian packages let default CLI configuration readable by all

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.0.0-M1
  • Fix Version/s: 5.0.0-RC-1
  • Component/s: Packaging
  • Security Level: Public
  • Description:
    Hide

    It would make sense to have them only readable to the user/group.

    Optionaly, it could make sense to have it assigned to petals/petals (and not root/root).
    Like this root can add a user to the petals group and let him use petals-cli with the default configuration.

    Show
    It would make sense to have them only readable to the user/group. Optionaly, it could make sense to have it assigned to petals/petals (and not root/root). Like this root can add a user to the petals group and let him use petals-cli with the default configuration.
  • Environment:
    -

Issue Links

Activity

Hide
Christophe DENEUX added a comment - Wed, 27 Jan 2016 - 17:43:13 +0100

I think you are talking about the files /etc/petals-cli/petals-cli.default and /etc/petals-registry-cli/petals-registry-cli.default.

Your idea is interesting. IMO, in the same way, Petals CLI and Petals Registry CLI should be runnable only by users member of the group petals. This is more restrictive but less easily usable because a user must added to the group petals before to be able to use CLIs.

What does our product owner think about this ?

Show
Christophe DENEUX added a comment - Wed, 27 Jan 2016 - 17:43:13 +0100 I think you are talking about the files /etc/petals-cli/petals-cli.default and /etc/petals-registry-cli/petals-registry-cli.default. Your idea is interesting. IMO, in the same way, Petals CLI and Petals Registry CLI should be runnable only by users member of the group petals. This is more restrictive but less easily usable because a user must added to the group petals before to be able to use CLIs. What does our product owner think about this ?
Hide
Victor NOËL added a comment - Thu, 28 Jan 2016 - 09:55:13 +0100

No no, I don't agree with the second point: it's bad practice to restrict the execution of the CLIs. Anyway if an user really wants it, he can install it locally.

The thing of first importance is: /etc/petals-cli/petals-cli.default and /etc/petals-registry-cli/petals-registry-cli.default are readable by everybody and it is a huge security risk.

The second point, less important is: do we want that user added to the petals group can read them?

Show
Victor NOËL added a comment - Thu, 28 Jan 2016 - 09:55:13 +0100 No no, I don't agree with the second point: it's bad practice to restrict the execution of the CLIs. Anyway if an user really wants it, he can install it locally. The thing of first importance is: /etc/petals-cli/petals-cli.default and /etc/petals-registry-cli/petals-registry-cli.default are readable by everybody and it is a huge security risk. The second point, less important is: do we want that user added to the petals group can read them?
Hide
Christophe DENEUX added a comment - Thu, 28 Jan 2016 - 10:34:44 +0100

You are right, if an user really wants a CLI, he can install it locally from ZIP archive.

I agree to restrict readability of configuration files to the members of group petals. If the user is not a member of the group, a warning should be displayed in mode 'console' (petals-cli -C): "Your are not granted to access the default configuration file: ...".

And don't forget to update the user documentation.

Show
Christophe DENEUX added a comment - Thu, 28 Jan 2016 - 10:34:44 +0100 You are right, if an user really wants a CLI, he can install it locally from ZIP archive. I agree to restrict readability of configuration files to the members of group petals. If the user is not a member of the group, a warning should be displayed in mode 'console' (petals-cli -C): "Your are not granted to access the default configuration file: ...". And don't forget to update the user documentation.

People

Dates

  • Created:
    Wed, 27 Jan 2016 - 09:27:41 +0100
    Updated:
    Thu, 28 Jan 2016 - 16:29:03 +0100
    Resolved:
    Thu, 28 Jan 2016 - 16:29:03 +0100