Why all the updates?

Yesterday was something of a record for the number of software updates released here. Let me explain.

Ulbow 1.0b3 was an intended update which makes this log browser feature-complete, with the ability to convert log extracts into CSV format. It also addresses two bugs: one which I detailed here on Sunday, which made it impossible for anyone whose settings use AM/PM time rather than the 24-hour clock to set many times using the DateStepper control. The other bug is that common to several other apps, explained below.

SilentKnight 1.6 was overdue, since Apple stopped supporting macOS Sierra. Macs which are still running Sierra will necessarily have older versions of EFI firmware than those running High Sierra and later, and that’s very unlikely to change. In previous versions, Sierra users were warned that their firmware was out of date and needed updating. As that’s no longer possible, I wanted to reduce that to the same caution as has been given for Macs running El Capitan and earlier.

Consolation 3.6, T2M2 1.12, Taccy 1.8 and Ulbow 1.0b3 all address the same bug which could prevent them from working on a very small number of Macs.

Those four apps (plus Cirrus) all access the unified log. In order to do so, the user must have admin rights, or the commands used to get log extracts will simply return nothing. This has been an undocumented limitation which Apple introduced after the first release of macOS Sierra. Since I started making log utilities available here, it has been the greatest reason for users reporting problems with them.

More recently, I have worked out a method of detecting whether the log show command should work, as I have been unable to find any direct way of discovering whether the current user has admin privileges. This works in two steps: the first obtains the short username of the current user, and the second tests whether that user is a member of group 80, admin.

The first step is easily accomplished in Swift, using the function ProcessInfo.processInfo.userName, which returns the user name as a string. This is then used as an argument to the id -G command, which returns a list of numbers of all the groups of which that user is a member. For example, my standard configuration here returns the string
20 501 12 61 79 80 81 98 399 504 500 502 701 33 100 204 250 400 503

There are several ways to confirm that group 80 is listed in that result. Simply looking for the string “80” isn’t reliable, as that would include false positives for groups 180, 801, and so on. So in my first implementation, the code looked for ” 80 “, with a leading and trailing space. Given the number of groups normally found in the result, and the fact that 80 appears well into the list, this appeared safe, specific and robust.

Then I got an email from Joe, whose user ID isn’t 501 as is normal, but that account is every bit a member of the admin group 80. The snag with id -G on his Mac is that it spits out the group 80 at the start of the list of groups, not in the middle. Not only that, but I thought that his user ID was also a member of far fewer groups (a misunderstanding on my part).

Clearly, some users with more unusual configurations and user IDs which are in the admin group were going to find that these apps wouldn’t recognise their privileges properly, and either refuse to run, or deny them features.

My solution is much more general. Instead of searching the whole list of groups using a string, that list is now turned into an array of strings, and the code looks to see whether any member of that array consists of the string “80”. Even if that user ID is only a member of one group, if that’s 80, then it’s acceptable.

Joe very kindly tested this change for me, and confirmed that it now works reliably for him. So I have fixed this bug in Consolation, T2M2, Taccy and Ulbow. Once I’m happy that it’s robust, I will add this test to determine whether Cirrus should offer its log window too.