Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission fixer scripts #6

Open
FedericoPonzi opened this issue Mar 7, 2020 · 2 comments
Open

Permission fixer scripts #6

FedericoPonzi opened this issue Mar 7, 2020 · 2 comments
Labels
feature Request a new feature

Comments

@FedericoPonzi
Copy link
Owner

FedericoPonzi commented Mar 7, 2020

Something similar to: https://github.com/just-containers/s6-overlay#fixing-ownership--permissions

Usually when you start a docker container, you want to fix permissions on the volumes (so needs to happen at runtime and not build time). Without this feature, you would need to create a service which runs and won't be restarted, which is a bit ugly because services are long running processes and one shot services are not suitable for being supervised.

The idea is to provide a format similar to s6-overlay's.

This is suitable if you want to avoid spawning another process and thus makes faster startups.

@FedericoPonzi FedericoPonzi added the feature Request a new feature label Mar 7, 2020
@FedericoPonzi
Copy link
Owner Author

FedericoPonzi commented Mar 7, 2020

The relevant section from the s6-overlay's docs:


Fixing ownership & permissions

Sometimes it's interesting to fix ownership & permissions before proceeding because, for example, you have mounted/mapped a host folder inside your container. Our overlay provides a way to tackle this issue using files in /etc/fix-attrs.d. This is the pattern format followed by fix-attrs files:

path recurse account fmode dmode
  • path: File or dir path.
  • recurse: (Set to true or false) If a folder is found, recurse through all containing files & folders in it.
  • account: Target account. It's possible to default to fallback uid:gid if the account isn't found. For example, nobody,32768:32768 would try to use the nobody account first, then fallback to uid 32768 instead.
    If, for instance, daemon account is UID=2 and GID=2, these are the possible values for account field:
    • daemon: UID=2 GID=2
    • daemon,3:4: UID=2 GID=2
    • 2:2,3:4: UID=2 GID=2
    • daemon:11111,3:4: UID=11111 GID=2
    • 11111:daemon,3:4: UID=2 GID=11111
    • daemon:daemon,3:4: UID=2 GID=2
    • daemon:unexisting,3:4: UID=2 GID=4
    • unexisting:daemon,3:4: UID=3 GID=2
    • 11111:11111,3:4: UID=11111 GID=11111
  • fmode: Target file mode. For example, 0644.
  • dmode: Target dir/folder mode. For example, 0755.

Here you have some working examples:

/etc/fix-attrs.d/01-mysql-data-dir:

/var/lib/mysql true mysql 0600 0700

/etc/fix-attrs.d/02-mysql-log-dirs:

/var/log/mysql-error-logs true nobody,32768:32768 0644 2700
/var/log/mysql-general-logs true nobody,32768:32768 0644 2700
/var/log/mysql-slow-query-logs true nobody,32768:32768 0644 2700

@FedericoPonzi
Copy link
Owner Author

I think with the same PR, we should add some general mechanism for system initialization.
I would like to see some intuitive directory hierarchy that allows system initialization, with: 1. permissions fixer scripts 2. one.shot scripts. I'm wondering if it would make sense to allow also "one shot services" which could be run as reaction to other services status. So something like:

type = oneshot
after = ["boot.service" : "exited"]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Request a new feature
Projects
None yet
Development

No branches or pull requests

1 participant