Karaf
  1. Karaf
  2. KARAF-798

Support for relocating karaf.history file

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.6, 3.0.0
    • Component/s: karaf-shell
    • Labels:
      None

      Description

      We have a servicemix-based product that has to perform a setuid to a lower-privileged user while running on linux. We've accounted for most permissions-based issues that result from doing this by ensuring that the lower-privileged user has write access to the necessary files under the data directory.

      Unfortunately, we can't do this with karaf.history since it is written to the home directory of the user that started the stack (root in this case). The lower-privileged usually doesn't have any visibility into this directory, let alone write privileges. If a configuration option was provided to specify the location of the karaf.history file (or the option to not even write or expect to find one), then we could treat this file like any other.

        Activity

        Hide
        Glen Mazza added a comment -

        A concern I have is that some of the commands in the history file might have sensitive data (e.g., "useradd bob password2"); being able to relocate it to a more openly readable location might pose security risks. If there could be a way, upon a setuid, to create a brand new history file in that user's home directory (ignoring the one in the root home directory), that might be a better solution.

        Show
        Glen Mazza added a comment - A concern I have is that some of the commands in the history file might have sensitive data (e.g., "useradd bob password2"); being able to relocate it to a more openly readable location might pose security risks. If there could be a way, upon a setuid, to create a brand new history file in that user's home directory (ignoring the one in the root home directory), that might be a better solution.
        Hide
        Troy Waldrep added a comment -

        Yeah, that would work as well. All we're looking for is a clean way to handle the use case.

        Show
        Troy Waldrep added a comment - Yeah, that would work as well. All we're looking for is a clean way to handle the use case.
        Hide
        Jean-Baptiste Onofré added a comment -

        As proposed by Troy, we can introduce a -Dkaraf.history.location property to define the history file location (it's the responsibility of the user to check the permission granted to this location).

        @Glen, could you explain what you have in mind ? Do you want to store this location as a branding properties (in the branding.properties file) ? Using setuid, what user you use, the Java process will only knows the root (the sticky user), it's system level, we don't have workaround for that.

        Show
        Jean-Baptiste Onofré added a comment - As proposed by Troy, we can introduce a -Dkaraf.history.location property to define the history file location (it's the responsibility of the user to check the permission granted to this location). @Glen, could you explain what you have in mind ? Do you want to store this location as a branding properties (in the branding.properties file) ? Using setuid, what user you use, the Java process will only knows the root (the sticky user), it's system level, we don't have workaround for that.
        Hide
        Glen Mazza added a comment -

        -Dkaraf.history.location as described looks fine. My only concern was that command taking an already existing karaf history file and relocating its contents to a different folder with different security permissions. That would be a security hole if the karaf history file potentially could have sensitive information within it, such as usernames and passwords in any type of "create user" command. But nobody here is proposing that.

        Granted, the new -Dkaraf.history.location might be (potentially incorrectly) world-readable, but that wouldn't be karaf's fault but just that of a careless system administrator. As you write, that's the responsibility of the user.

        Show
        Glen Mazza added a comment - -Dkaraf.history.location as described looks fine. My only concern was that command taking an already existing karaf history file and relocating its contents to a different folder with different security permissions. That would be a security hole if the karaf history file potentially could have sensitive information within it, such as usernames and passwords in any type of "create user" command. But nobody here is proposing that. Granted, the new -Dkaraf.history.location might be (potentially incorrectly) world-readable, but that wouldn't be karaf's fault but just that of a careless system administrator. As you write, that's the responsibility of the user.
        Hide
        Jamie goodyear added a comment -

        Bumping out to 2.2.6

        Show
        Jamie goodyear added a comment - Bumping out to 2.2.6
        Hide
        Jamie goodyear added a comment -

        Bumping to 3.1.0 - if we gain a consensus for how we want to approach the relocatable history file then we may bring this back to 3.0.0 to fix.

        Show
        Jamie goodyear added a comment - Bumping to 3.1.0 - if we gain a consensus for how we want to approach the relocatable history file then we may bring this back to 3.0.0 to fix.
        Hide
        Jean-Baptiste Onofré added a comment -

        protected File getHistoryFile()

        { return new File(System.getProperty("karaf.history", new File(System.getProperty("user.home"), ".karaf/karaf.history").toString())); }

        So, using -Dkaraf.history allows you to define the location of the history file (and it falls back to .karaf/karaf.history in the user home if not defined).

        Show
        Jean-Baptiste Onofré added a comment - protected File getHistoryFile() { return new File(System.getProperty("karaf.history", new File(System.getProperty("user.home"), ".karaf/karaf.history").toString())); } So, using -Dkaraf.history allows you to define the location of the history file (and it falls back to .karaf/karaf.history in the user home if not defined).

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Troy Waldrep
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development