3 ms·

I'd love it if some more common things that are done in postint scripts could be done in a declarative way, like adding system users. And then there are things

I'd love it if some more common things that are done in postint scripts could be done in a declarative way, like adding system users. And then there are things that are declarative in the debian/ dir (like auto-(re)starting the installed services) that end up as generated, procedural code in the postinst script. When such things can be done in a declarative manner, it's much easier to reason about them programmatically, and maybe you could completely disable postinst scripts for a whole category of packages.

brazzledazzle 8y ago
When I first learned how Debian (and other) packages were put together I was somewhat surprised. Not just by the security implications but also by the inherent complexity. Even if you’re using templates and generators you can gain a lot by moving all of that out of the package and into the package manager/installer. Distribution-level changes, user OS customization and possibly even reduced privileges would become easier to handle. On the package manager side it seems like maintainability would (in the general case) vastly increase.
- bluGill 8y ago
  There is a downside though: if you forget something in the declarative tool it cannot be done. Using bash scripts lets a good programmer get what they need done. Using declarative makes it easier to do everything we thought of but some things are accidentally impossible. I think an escape to bash might always be required, but I think it should be a restrictive thing. That is packages with that flag require a special flag passed to dpkg. Also any packages using bash should automatically get extra reviewers.
mnw21cam 8y ago
I agree. I would imagine that the vast majority of packages could easily be marked as "doesn't run anything as root, doesn't install any SUID executables", with enforcement from APT. This then reduces the attack/bug surface to those packages that do need to do dangerous things.
JdeBP 8y ago
I addressed this in my packages with a roughly declarative language that turned into shell functions in a Debian, Arch, or FreeBSD package (by dint of prefixing with a shell function library) and into the packing list format for OpenBSD (by dint of an awk script). Examples: # dedicated user accounts file_owning_user "cron" "/var/spool/cron" directory "cron" "/var/spool/cron" "0755" directory "cron" "/var/spool/cron/tmp" "0700" directory "cron" "/var/spool/cron/crontabs" "0700" # bcron services service_with_dedicated_logger "bcron-start" service_with_dedicated_logger "bcron-update" socket_with_dedicated_logger "bcron-spool" # user-mode TTYs user_tty "vc1-tty" user_tty "vc2-tty" user_tty "vc3-tty" service_with_dedicated_logger "terminal-emulator@vc1" service_with_dedicated_logger "terminal-emulator@vc2" service_with_dedicated_logger "terminal-emulator@vc3" login_service_with_dedicated_logger "vc1-tty" login_service_with_dedicated_logger "vc2-tty" login_service_with_dedicated_logger "vc3-tty" # TTY ancillaries service_with_dedicated_logger "console-input-method@head0" service_with_dedicated_logger "console-multiplexor@head0" service_with_dedicated_logger "console-fb-realizer@head0" There are different shell function mappings for pre/post-install/remove/update, making what (say) "login_service_with_dedicated_logger" does vary according to the action being taken and whether the package is a "tools" package or a "run" package. In the post-install of a "tools" package it creates dedicated user accounts and log file directories. In the post-install of a "run" package it conditionally enables and starts services. It still needed the ability to run general-purpose commands here and there, especially to perform tidying up as things were renamed and errors were corrected over the years, and the number of declarative verbs that one turns out to need in practice is quite large.

brazzledazzle 8y ago

When I first learned how Debian (and other) packages were put together I was somewhat surprised. Not just by the security implications but also by the inherent complexity. Even if you’re using templates and generators you can gain a lot by moving all of that out of the package and into the package manager/installer. Distribution-level changes, user OS customization and possibly even reduced privileges would become easier to handle. On the package manager side it seems like maintainability would (in the general case) vastly increase.

bluGill 8y ago
There is a downside though: if you forget something in the declarative tool it cannot be done. Using bash scripts lets a good programmer get what they need done. Using declarative makes it easier to do everything we thought of but some things are accidentally impossible. I think an escape to bash might always be required, but I think it should be a restrictive thing. That is packages with that flag require a special flag passed to dpkg. Also any packages using bash should automatically get extra reviewers.

mnw21cam 8y ago

I agree. I would imagine that the vast majority of packages could easily be marked as "doesn't run anything as root, doesn't install any SUID executables", with enforcement from APT. This then reduces the attack/bug surface to those packages that do need to do dangerous things.

JdeBP 8y ago

I addressed this in my packages with a roughly declarative language that turned into shell functions in a Debian, Arch, or FreeBSD package (by dint of prefixing with a shell function library) and into the packing list format for OpenBSD (by dint of an awk script). Examples: # dedicated user accounts file_owning_user "cron" "/var/spool/cron" directory "cron" "/var/spool/cron" "0755" directory "cron" "/var/spool/cron/tmp" "0700" directory "cron" "/var/spool/cron/crontabs" "0700" # bcron services service_with_dedicated_logger "bcron-start" service_with_dedicated_logger "bcron-update" socket_with_dedicated_logger "bcron-spool" # user-mode TTYs user_tty "vc1-tty" user_tty "vc2-tty" user_tty "vc3-tty" service_with_dedicated_logger "terminal-emulator@vc1" service_with_dedicated_logger "terminal-emulator@vc2" service_with_dedicated_logger "terminal-emulator@vc3" login_service_with_dedicated_logger "vc1-tty" login_service_with_dedicated_logger "vc2-tty" login_service_with_dedicated_logger "vc3-tty" # TTY ancillaries service_with_dedicated_logger "console-input-method@head0" service_with_dedicated_logger "console-multiplexor@head0" service_with_dedicated_logger "console-fb-realizer@head0" There are different shell function mappings for pre/post-install/remove/update, making what (say) "login_service_with_dedicated_logger" does vary according to the action being taken and whether the package is a "tools" package or a "run" package. In the post-install of a "tools" package it creates dedicated user accounts and log file directories. In the post-install of a "run" package it conditionally enables and starts services. It still needed the ability to run general-purpose commands here and there, especially to perform tidying up as things were renamed and errors were corrected over the years, and the number of declarative verbs that one turns out to need in practice is quite large.