[
https://issues.apache.org/jira/browse/RANGER-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pradeep Agrawal updated RANGER-2139:
------------------------------------
Fix Version/s: (was: master)
> 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, 0.7.1
> 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() function.
> * 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 group01).
> * 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
(v8.3.4#803005)
