3 ms·

AGPLv3 https://github.com/Kharacternyk/klunok/blob/v1.0.2/LICENSE https://github.com/Kharacternyk/klunok/blob/v1.0.2/LICENSE but also > Klunok uses the Linux

AGPLv3 https://github.com/Kharacternyk/klunok/blob/v1.0.2/LICENSE https://github.com/Kharacternyk/klunok/blob/v1.0.2/LICENSE but also > Klunok uses the Linux kernel fanotify API, which as of now requires root privileges. Therefore, Klunok should be invoked, for example, with sudo

Kharacternyk 3y ago
Yes, the sudo bit is a drawback. The daemon drops privileges early, though. There is some work in the kernel space for rootless fanotify, which I look forward to. There is already some rootless fanotify API, but it requires holding onto a dangerous capability for the whole lifetime of the daemon, which appears worse than the current implementation to me.
enasterosophes 3y ago
What would be the reason they used fanotify instead of inotify? I used inotify before and didn't require special permissions. I want to suppose that inotify supports the klunok use case, but maybe I've overlooked something. Also, I wonder what capabilities(7) would be sufficient, instead of requiring full-blown sudo powers. I saw a stackoverflow answer which suggested CAP_SYS_ADMIN, but they didn't provide a source for that claim. Edit: Actually, the capabilities manpage does match fanotify_init to CAP_SYS_ADMIN. So, there's a source. Disappointing as it is.
- Kharacternyk 3y ago
  inotify doesn't tell which process writes to a file, and Klunok is all about tracking only files edited by a human. Also, monitoring entire subtrees with inotify is painful and prone to race conditions.
  - pushfoo 3y ago
    Why only the files edited by a human? What about edge cases where changes made by a program, such as a linter or auto-formatter? Those aren't guaranteed to be integrated into an IDE.
    - Kharacternyk 3y ago
      That's all right if they are not integrated into an IDE. The typical scenario is: a file is edited by a human -> linter/formatters run -> 60 seconds delay -> the file is backed up. Therefore, debouncing has a handy side-effect of letting linters/formatters run before a version of the file is stored.
  - az09mugen 3y ago
    Shouldn't it be simpler to just specify just a directory (of a project for example) in which klunok tracks and saves modifications of all the files inside that said directory ? Anyway I'm not giving sudo rights just to replace git. And also depending on the number of files, the size of the files and the frequency of edit/save, it can become a mess. It may fit some needs but not mines. Interesting though.

Kharacternyk 3y ago

Yes, the sudo bit is a drawback. The daemon drops privileges early, though. There is some work in the kernel space for rootless fanotify, which I look forward to. There is already some rootless fanotify API, but it requires holding onto a dangerous capability for the whole lifetime of the daemon, which appears worse than the current implementation to me.

enasterosophes 3y ago

What would be the reason they used fanotify instead of inotify? I used inotify before and didn't require special permissions. I want to suppose that inotify supports the klunok use case, but maybe I've overlooked something. Also, I wonder what capabilities(7) would be sufficient, instead of requiring full-blown sudo powers. I saw a stackoverflow answer which suggested CAP_SYS_ADMIN, but they didn't provide a source for that claim. Edit: Actually, the capabilities manpage does match fanotify_init to CAP_SYS_ADMIN. So, there's a source. Disappointing as it is.

Kharacternyk 3y ago
inotify doesn't tell which process writes to a file, and Klunok is all about tracking only files edited by a human. Also, monitoring entire subtrees with inotify is painful and prone to race conditions.
- pushfoo 3y ago
  Why only the files edited by a human? What about edge cases where changes made by a program, such as a linter or auto-formatter? Those aren't guaranteed to be integrated into an IDE.
  - Kharacternyk 3y ago
    That's all right if they are not integrated into an IDE. The typical scenario is: a file is edited by a human -> linter/formatters run -> 60 seconds delay -> the file is backed up. Therefore, debouncing has a handy side-effect of letting linters/formatters run before a version of the file is stored.
- az09mugen 3y ago
  Shouldn't it be simpler to just specify just a directory (of a project for example) in which klunok tracks and saves modifications of all the files inside that said directory ? Anyway I'm not giving sudo rights just to replace git. And also depending on the number of files, the size of the files and the frequency of edit/save, it can become a mess. It may fit some needs but not mines. Interesting though.