| Re: [chrony-dev] create_dir in util.c - permissions |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] create_dir in util.c - permissions
- From: Bryan Christianson <bryan@xxxxxxxxxxxxx>
- Date: Mon, 23 Nov 2015 21:44:19 +1300
- Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0-2; h=Feedback-ID:X-Smtpcorp-Track:To:Message-Id:Date: From:Subject; bh=yDwtgu1ZhuSn5vUMCK2ebW+xu+vEipTKTdQiKYVQkzw=; b=ZioYvZlMo4ZK X19TP3E5Sm2A8bGHzcwEWv4zk4qr6XOEQJUiA0xdFxPYIMVL+aXPGRgOAk/kFVVdRcv499Bauuvgg cLm/nX9ddSoZzkTNUmJJYrbrQxzx2Btnkf1xbm0ZXbD7Ag6g7oMHdSEt+n9gHZB95LmxiBXvB7B7o SftrchwKNir0W22gfanuNyE+MrcK2VMRjT5uW2pC1/16bSkKjJabORcGcpbSZGuN5FT5Iib0rJYH6 jYWd+jDsL7qhFEFp4pn/WwiceEgX+jt2Wa1q68eZKz9pS07O300zvcoFwihmlyvv5EXmEYtSkQrLG Gp5cS1PJx9UQwpFMwAsTGA==;
- Feedback-id: 149811m:149811acx33YQ:149811sSBifv5Y_w:SMTPCORP
> On 23/11/2015, at 8:29 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
>
> On Sat, Nov 21, 2015 at 01:37:37PM +1300, Bryan Christianson wrote:
>> Something I noticed when enabling a non-privileged user after having previously been running chronyd as root.
>>
>> If a directory already exists, create_dir just returns
>>
>> if (S_ISDIR(buf.st_mode))
>> return 1;
>> LOG(LOGS_ERR, LOGF_Util, "%s is not directory", p);
>> return 0;
>>
>>
>> I think there should be a call to chown(p, uid, gid) before the return.
>
> I'm not sure. I think that could be a dangerous operation. What if
> someone misunderstood the requirements and set the socket path to
> /var/run for instance?
>
>> Not sure what to do with any existing directory contents. Maybe they should also be chown() 'd.
>
> Probably better to not assume anything about the content.
>
>> Or maybe the system administrator should be doing all this manually. :)
>
> Yes, I'd rather leave that up to the admin or a package postinstall
> script to allow an upgrade to a configuration dropping root
> privileges.
>
> Isn't /var/run typically localted on a ramdisk or at least cleaned on
> boot? In the worst case reboot should be able to fix it.
>
/var/run isn't really the problem because reboot does clean all that up. Its logdir, dumpdir and drigtfile that have problems and the non-privileged daemon is unable to update them. And the error is easily missed because its not a show stopper, just a warning message in the syslog. (I wondered why my graphs stopped updating after switching to non-privileged mode)
Anyway, its not a big problem and can be easily worked around by scripts or manual intervention.
B
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.