Allow sudo selfcontrol-cli to start a block without reinstalling selfcontrold

[EternalDebugger]

Is your feature request related to a problem? Please describe.
I'm testing a use case where the main user of the Mac Laptop is a Standard user, and is not supposed to have admin password. I'd like this user can still trigger a block without entering the admin password, as the user is not supposed to know it.

The approach I'd like to use is to grant this user access to sudo selfcontrol-cli without password via sudoers file. This will also allow selfcontrol-cli to call launchctl load as superuser. Given that /Library/PrivilegedHelperTools/org.eyebeam.selfcontrold should already be installed, this can smooth the experience as it can avoid the unnecessary privilege escalation dialog which requires admin password. It will also allow cronjob to automatically schedule blocks, fulfilling one of the most requested features in this repo.

The following is the sudoers file I'm testing with:

mainuser ALL=(ALL) NOPASSWD: /Applications/SelfControl.app/Contents/MacOS/selfcontrol-cli

There are two hurdles I ran into with this approach:

1. the daemon automatically unload after two minutes, this can be easily resolved by updating INACTIVITY_LIMIT_SECS = 60 * 60 * 24 * 365 * 10 in Daemon/SCDaemon.m and rebuild selfcontrold.
2. However, it appears in the logic of cli-main.m, it always calls installDaemon, which runs SMJobRemove and SMJobBless, both will require privilege escalation dialog and admin password, hence defeating the purpose of what I want to achieve.

Is there a way to avoid calling installDaemon function but still allow selfcontrol-cli to start a blocking session?

[EternalDebugger]

This is the small hack I'm trying to get working,

$ git diff
diff --git a/Common/SCXPCClient.m b/Common/SCXPCClient.m
index 5436c73..0590fba 100644
--- a/Common/SCXPCClient.m
+++ b/Common/SCXPCClient.m
@@ -359,6 +359,7 @@ - (NSString*)selfControlHelperToolPath {
     dispatch_once(&onceToken, ^{
         NSBundle* thisBundle = [NSBundle mainBundle];
         path = [thisBundle.bundlePath stringByAppendingString: @"/Contents/Library/LaunchServices/org.eyebeam.selfcontrold"];
+        path = @"/usr/local/bin/org.eyebeam.selfcontrold";
     });

     return path;
diff --git a/Daemon/SCDaemon.m b/Daemon/SCDaemon.m
index 3fd746a..7e99395 100644
--- a/Daemon/SCDaemon.m
+++ b/Daemon/SCDaemon.m
@@ -12,7 +12,7 @@
 #import "SCFileWatcher.h"

 static NSString* serviceName = @"org.eyebeam.selfcontrold";
-float const INACTIVITY_LIMIT_SECS = 60 * 2; // 2 minutes
+float const INACTIVITY_LIMIT_SECS = 60 * 60 * 24 * 365 * 10; // 10 years

 @interface NSXPCConnection(PrivateAuditToken)

diff --git a/cli-main.m b/cli-main.m
index 46958cc..28ca8f3 100755
--- a/cli-main.m
+++ b/cli-main.m
@@ -180,7 +180,8 @@ int main(int argc, char* argv[]) {
             // while our blocks are still running
             dispatch_semaphore_t installingBlockSema = dispatch_semaphore_create(0);

-            [xpc installDaemon:^(NSError * _Nonnull error) {
+            [xpc refreshConnectionAndRun:^{
+                NSError *error = nil;
                 if (error != nil) {
                     NSLog(@"ERROR: Failed to install daemon with error %@", error);
                     exit(EX_SOFTWARE);

The only hurdle is I don't have an Apple Developer Account and cannot sign the binaries with TeamIdentity setting to a real Developer ID, so I always get the following error:

Rejecting XPC connection because of invalid client signing. Error was Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)"

[EternalDebugger]

If there's interest in pursuing this direction, I'm happy to help out.

[skar2307]

@EternalDebugger Did you have any issues with Sentry when you were coming up with the hack for this issue? I've been trying to fix a couple bugs that have been ruining my personal experience with SelfControl, as you can see here. However, I'm unable to get past the issues I'm having with Sentry.

This is for a work computer so SelfControl is the only approved option I can use. I don't have an Apple Developer account either so I'll probably face the same XPC issue that you are at some point. It's unfortunate that there's no longer any support from the original devs so even if a PR was put out, I doubt it would get merged in.