Group write permissions /etc/asterisk/.

Home » Asterisk Users » Group write permissions /etc/asterisk/.
Asterisk Users 10 Comments

I notice that the installation of Asterisk 1.8.8 thru 1.8.10 (probably
earlier versions too) remove the group write permissions from
/etc/asterisk/. which is different than 1.4. And 1.6.

Is this expected behavior?
If so, what’s the rationale?
If not, I’ll submit a bug report if someone hasn’t beaten me to it.

-K

10 thoughts on - Group write permissions /etc/asterisk/.

  • The difference comes from using `install` rather than `mkdir`. mkdir
    defaults to a+rwx (777) – umask (likely 002 on your system), whereas
    install defaults to the much more sane u+rwx,g+rx,o+rx (755).

    I don’t know if I would call it a bug since the switch to install was
    intentional, but I wouldn’t say it’s necessarily expected either. I
    don’t really have a strong opinion either way though. If anything, I
    might be inclined to argue that 750 (or 770) would be more appropriate.

  • Considering that (e.g.) sip.conf and iax.conf may contain passwords in
    clear-text, I’d agree that 770/750 for directories and 660/640 for files
    would be most appropriate. The g+w bit needs to be set only on those
    directories/files that ought to be writable from within the Asterisk
    process itself.

    Regards,

  • It’s not a question of whether the default directory permissions are
    appropriate. I agree with those.

    What we’re talking about here is what happens during updates to an existing
    directory. I can’t see any rationale for changing the group permissions.
    If the group permissions differ from the installation defaults, it is
    because the sysadmin needed them to be different in order to implement one
    or more methods of extensibility / interoperability that make Asterisk so
    powerful.

    Absolutely, it would make sense for the installer to check to be sure it
    has SUFFICIENT permissions to operate properly, but it is a huge leap of
    faith to assume that it’s appropriate to simply delete certain group
    permissions. Users only in the owner’s group if they belong there, no??

    The upshot is that ever since upgrading to 1.8 we have to re-re-re-reset
    the group directory permissions to make things work, and that just seems
    insane to me if that is a design choice, not a regression.

    -Karl

    On Mon, Mar 5, 2012 at 11:30 PM, Raj Mathur (राज माथुर) <
    raju@linux-delhi.org> wrote:

  • It should only set them if the directory does not exist. If it’s changing them,
    something is very seriously broken.

  • [snip]

    An RPM which updates a previous version will change the user/group &
    permissions of any existing directory or file as it is instructed to.
    I just tested it on CentOS 6 to verify:

    1) RPM #1 installs /etc/test and file /etc/test/mytest.txt
    user/group = asterisk/asterisk, dir/file perms are 0750/0640

    2) manually change user/group/perms of directory/file to
    something else

    3) RPM #2 updates RPM #1. RPM #2 sets user/group to asterisk/asterisk
    and dir/file perms to 0750/0640. So it’s back to the original
    settings from the spec file.

    Not setting user/group ownership and permissions will make rpmbuild use
    defaults (iirc root:root for ownership, 755 perms for directories and
    644 perms for files).

    Regards,
    Patrick

  • He didn’t suggest that he was talking about RPMs. If that’s the case, then I
    take back everything I said.

  • Reading back you’ve got a point there. If Karl wasn’t talking about RPMs
    then ditto 🙂 Guess I mixed the thread about the 1.8.9.3 RPM
    availability and this one and assumed it was about RPM.

    Regards,
    Patrick

  • This is a result of changing from

    $ mkdir -p /etc/asterisk

    to

    $ install -d /etc/asterisk

    Install will blindly overwrite existing permissions if the directory
    already exists. When I did the initial patch, I added logic to check if
    the directory already exists on the file system, if so, skip re-creating
    the directory. I even noted this issue on reviewboard[1], however it
    was never implemented.

    [1] https://reviewboard.asterisk.org/r/654/#review2370