Clovertech

directory permissions for LogHistory

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › directory permissions for LogHistory

  • Creator
    Topic
  • December 16, 2008 at 5:41 pm #50516
    Kevan Riley
    Participant

      When we enable Log History for a site, the LogHistory directories that are created have the following permissions:

      drwxr-S—

      Why is this?  It is causing us trouble.

      PS this is CL 5.6r2  on AIX 5.3.

      Kevan

    • Creator
      Topic
    Viewing 6 reply threads
    • Author
      Replies
      • December 16, 2008 at 6:57 pm #66426
        Anonymous
        Participant

          What kind of issue is it causing you ?

        • December 16, 2008 at 7:04 pm #66427
          Kevan Riley
          Participant

            Well two issues.  Simplest one is that if you are a user other than “hci” even though you are in the same group ‘staff’ you cannot ‘cd’ into ‘LogHistory’.  If it were the lowrcase “s” I thing that allows for changing into the directory, but not for the capital “S”.  We use the lowercase “s” for our OutboundSave and InbounSave directories w/o problems.

            Second is, well, I was hoping to understand why this was done.  What I’d really like to do is create LogHistory directories as links in advance.  We like to keep our archive stuff outside of our process directory space.  But, it seems like it was not working right when I tried creating the links in advance.

            Kevan

          • December 16, 2008 at 7:17 pm #66428
            Rob Abbott
            Keymaster

              Most likely has to do with the umask of the user that is creating the directories.

              Rob Abbott
              Cloverleaf Emeritus

            • December 17, 2008 at 4:45 pm #66429
              Robert Milfajt
              Participant

                S and s are referred to as the “Sticky Bit” in Unix.  The Sticky Bit is usually associated with world writeable directories, such as the /tmp directory. This prevents users from deleting files they don’t own. Users can write to those directories but only they can delete or update those files they own. It’s commonly used for scratch directories like /tmp to provide some security for otherwise world-writable directories.

                The S means that someone applied the Sticky Bit security to r–.  The s means they applied the Sticky Bit security to r-x.  The underlying problem is that you are not getting xecute permission, which is preventing you from changing to the directory, the S vs. s just hightlights the problem.  You need to set the umask of the user to make sure new directories are created with group permission of r-x or rwx.  This will change your S to s.

                Hope this helps,

                Robert Milfajt
                Northwestern Medicine
                Chicago, IL

              • December 17, 2008 at 8:49 pm #66430
                Kevan Riley
                Participant

                  Yep that was it.  Thanks for the additional clarification.  Rob was right, but I was not clear how the umask interacted with the setting of the sticky bit.  Your added information connected it for me.

                  Thanks

                  Kevan

                • April 6, 2009 at 2:13 pm #66431
                  Gary Atkinson
                  Participant

                    I have issue where the process log will not cycle.

                  • April 7, 2009 at 12:17 pm #66432
                    Gary Atkinson
                    Participant

                      I adjusted the max size to 15MB and bounced the process, and…. the cycling is now working!  Thanks to Jimmy in support  8)

                  • Author
                    Replies
                  Viewing 6 reply threads
                  • The forum ‘Cloverleaf’ is closed to new topics and replies.