ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cetin Sahin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (RANGER-2139) UnixUserGroupBuilder fails to detect consecutive updates on UNIX passwd and group files
Date Thu, 21 Jun 2018 19:22:00 GMT

     [ https://issues.apache.org/jira/browse/RANGER-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Cetin Sahin updated RANGER-2139:
    Attachment: 0001-RANGER-2139-Fix-UnixUserGroupBuilder.patch

> UnixUserGroupBuilder fails to detect consecutive updates on UNIX passwd and group files
> ---------------------------------------------------------------------------------------
>                 Key: RANGER-2139
>                 URL: https://issues.apache.org/jira/browse/RANGER-2139
>             Project: Ranger
>          Issue Type: Bug
>          Components: usersync
>    Affects Versions: 1.0.0, master
>            Reporter: Cetin Sahin
>            Priority: Critical
>         Attachments: 0001-RANGER-2139-Fix-UnixUserGroupBuilder.patch
> When Unix based user and group synchronization is enabled in Ranger, UnixUserGroupBuilder
periodically checks whether one of the /etc/passwd or /etc/group files is modified or not
to trigger a synchronization.
> However, while checking the modification of a file, the UnixUserGroupBuilder uses java.io.File.lastModified()
to check whether the file is updated after the latest synchronization time.
> {code:java}
> long TempGroupFileModifiedAt = new File(unixGroupFile).lastModified();
> {code}
> java.io.File.lastModified() function, however, returns the latest modified timestamp
in the time granularity of seconds. That means each timestamp ends with 000 independent of
the millisecond precision.
> [https://bugs.openjdk.java.net/browse/JDK-8177809]
>  [http://dev-answers.blogspot.com/2014/11/avoid-using-javaiofilelastmodified-for.html]
> This can cause UnixUserGroupBuilder to fail to detect the update on the file if the file
modification check happens between the two consecutive updates within the same second. Assume
the following scenario with the corresponding timestamps where UnixUserGroupBuilder checks
the updates per minute.
> the latest modification of users and group files are at t0 (00:00:00.111), which have
a corresponding timestamp of 1529539200111, denoted by T0
> Now, consider the following scenario.
>  * At time t1 (01:*00:00.123*), T1 (1529542800123): /etc/group file is updated and a
new group called group01 is added.
>  * At time t2 (01:*00:00.345*), T2 (1529542800345): UnixUserGroupBuilder threads wakes
up and detects the update on the group file and performed the synchronization. After the synchronization,
the latest modification time for the group is updated from the File.lastModified() function.
latest modification of group file = File.lastModified(t1) = *1529542800000*. Please note that
the last 3 digits corresponding to the milliseconds is truncated to 000 with File.lastModified()
>  * At time t3 (01:*00:00.567*), T3 (1529542800567): /etc/group file is updated and a
user membership is added to one of the groups (e.g., user user01 becomes a member of group
>  * At time t4 (01:*01:00.345*), T4 (1529542860345): UnixUserGroupBuilder thread wakes
up and couldn't detect any changes since the timestamp generated from the File.lastModified()
function returns the same timestamp for t1 and t3. Recall that the latest modification time
of the group file becomes 1529542800000 at t2 and File.lastModified(t3) returns *1529542800000*
as well. Since both File.lastModified(t1) = File.lastModified(t3), UnixUserGroupBuilder could
not detect the modification on the file at t4, assumes there is no update, and then, sleeps
again without syncing the changes.
> At time t4, UnixUserGroupBuilder is supposed to sync the user group membership but if
fails to detect the update. If there is no any further update on one of these files, the user01
will never be part of group01 in Ranger.

This message was sent by Atlassian JIRA

View raw message