On Tue, 2016-08-16 at 21:20 +0200, Paul Gevers wrote: > The intent is that dbconfig indeed support identd based > authentication. I see.. hmm well wouldn't be my first choice for security reasons,... but I think it should be possible to get "full" support even with supporting identd as well.
> But indeed, normally we run under root (which IS the common domain > during installation/configuration of packages in the Debian.) Well as I said, it might be, that the UNIX user that dbconfig runs as already affects the actual authentication... so perhaps it's worth to generally allow people to specify which UNIX-user to run under in addition. But once should probably also put some warnings in place, that this really requires people to know what they're doing. > > (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. Well... it's based on... let's call it personal experience... I work for a university and we run a Tier-2 for the LHC Computing Grid using a massive storage management software called dCache, which every now and then changes its DB schemas (uses Postgres as well ;) )... Their policy is usually also not to complain loudly/fail when things are already there (e.g. when a site already created an index or so), which over time resulted in many sites having different schemas even though running the same version. IMO this creates rather more problems than sites solve by having some freedom of flexibility. Therefore, I'd say it's better to warn one time too often than not. And keep in mind that just by using TCP doesn't mean that the DB is actually remote,... this is e.g. the case in dCache which is written in Java (which doesn't support UNIX sockets for DB connections AFAIK). > > 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. Hmm this is in fact a valid point... > 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. Sure :) > > 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). Well as I've said at some point... most of this should be firstly considered brainstorming... it doesn't mean per se that it needs or should be implemented :) > So > the > logic in the main part should not be geared TOO much against > PostgreSQL. Sure... :) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
