Hi On 15-08-16 23:05, Christoph Anton Mitterer wrote: > On Mon, 2016-08-15 at 22:11 +0200, Paul Gevers wrote: > But in these specific cases (i.e. installation to a remote system), the > UNIX user under which we run psql/etc. locally shouldn't matter at al > (that is unless the remote DB server would e.g. use identd based auth > (with the local users), or similar things like GSSAPI).
The intent is that dbconfig indeed support identd based authentication. But indeed, normally we run under root (which IS the common domain during installation/configuration of packages in the Debian.) > (1) There is a dedicated dbconfig user, this is the user under which > any SQL, DB-clients, etc. are run, regardless of whether TCP or > UNIX sockets, regardless of whether locally or remotely This is putting even higher requirements on the (remote) database. I really don't like this approach as it also makes stuff more complicated (to check for). > (3) For certain operations (user creation, DB creation and similar), > i.e. all the things a remote DB admin wouldn't typically grant > normal users but supply them with,... dbconfig should: > first check if that already exists (perhaps try to use it and see > if that works - if possible) and if it does, not creating it again > but simply continuing with the DB-non-admin-user stuff That is exactly what my pending upload is going to do. > Perhaps a warning should be given, if the user/db already exists, > asking whether one wants to (try to) continue (after all, the admin > could have accidentally given you access to something). What do you have in mind here exactly? I guess this is more of an issue for UNIX sockets than for password access, because if the admin tells me the right password, it must be expecting that I am going to do something. > Pros: > - we don't run any commands (locally) under UNIX users "postgres" or > "root", which are not "our" (i.e. dbconfig's) domain and thus it's > good for privilege separation. We already run under root and that is quite normal. On localhost MariaDB I even need to be root to have the UNIX socket (like "postgres" for PostgreSQL). > we don't run any commands under arbitrary other users like "icinga" > or "phpbb" either, which are again not "our" users and we shouldn't > su to them unless really necessary. Well, here we may disagree. I think the package icinga is using dbconfig to do the DB setup, but it is the package icinga that is running the install. > - shouldn't make a difference whether remote DB or local, unless the > remote user name is somehow transported to the remote side (GSSAPI, > identd etc). Which is in principle supported. > Cons: > - appropriate auth rules need to be in place on the DB server side, > that allow the dbconfig user to do its business > => could be provided by the packages in theory... Again, not for remote hosts. Biggest argument against this (more complex) scheme. > And we could even provide sensible defaults depending on which users > we find, or whether it was detected that a remote DB server was given > (of course this is just heuristics). I believe the heuristics already greatly improved between jessie and jessie-backports/strech, so maybe some of your ideas are already in place in a way. >> True for local DB servers, but not for remote hosts. > Same as above... if the remote (or local) server doesn't give you DB- > amin-rights... we never can do anything about it... just check whether > the databases/DB-users we want to use already exist and move on if they > do. Ok, so here is something were some of my answered may be biased by: the (current) design and implementation of dbconfig. I think some of your ideas may be good/valid, but need extensive rewrite (for not enough? gain). Remember (or note, not sure how aware you are) that the core of dbconfig doesn't really care what DB you are talking to, MySQL/MariaDB, PostgreSQL, SQLite/SQLite3 and in the near future maybe MongoDB. So the logic in the main part should not be geared TOO much against PostgreSQL. Paul
signature.asc
Description: OpenPGP digital signature
