Bug#316127: Status?
sean finney wrote: hey guys, On Mon, May 15, 2006 at 11:03:34AM +0200, Olaf van der Spek wrote: Storing it in a file also has the advantage that it's less likely to get lost. the same argument would apply for the system root password :) Would it? Without being able to login, it's kinda hard to read the file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
hey guys, On Mon, May 15, 2006 at 11:03:34AM +0200, Olaf van der Spek wrote: Storing it in a file also has the advantage that it's less likely to get lost. the same argument would apply for the system root password :) to that, but i think i still like prompting the admin for a real password and not storing it anywhere. Isn't doing that via debconf unsafe too? if the password was kept in debconf, it would be equivalent to keeping the password in a file readable only by root like you have suggested (debconf passwords are kept in a root:root 600 file). *however*, any implementation should certainly reset the password after it is no longer needed, which is much more secure. more precisely: the password would be prompted from the user during pre-configuration, and then used/unset in the postinst. On Mon, May 15, 2006 at 11:36:35AM +0200, Christian Hammers wrote: I didn't follow the discussion but just want to throw in two points that - Debconf seems to have a way of storing passwords in a secure way, I have a passwords file in /var/lib/debconf well, it's no more secure than storing it in /etc/mysql/rootpassword.txt or similar, see the above comments. - Asking for passwords complicates automated installs so autogen one at least if debconf is not run interactively. i would argue that if we're doing an automated/non-interactive install, we should do exactly nothing for this, because the person doing the install probably knows more than we do about what's going on (like an FAI install, for example, which may set the password later via a script). sean -- signature.asc Description: Digital signature
Bug#316127: Status?
sean finney wrote: hi olaf, On Sun, May 14, 2006 at 10:20:55PM +0200, Olaf van der Spek wrote: So could you please explain what part of your 'general principle' is against communicating a random password to the administrator? placing it in a file would be less of an issue, and i'm not as opposed Storing it in a file also has the advantage that it's less likely to get lost. to that, but i think i still like prompting the admin for a real password and not storing it anywhere. Isn't doing that via debconf unsafe too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
Hi I didn't follow the discussion but just want to throw in two points that come to my mind, you don't need to comment them if you already discussed them... On 2006-05-15 Olaf van der Spek wrote: On Sun, May 14, 2006 at 10:20:55PM +0200, Olaf van der Spek wrote: So could you please explain what part of your 'general principle' is against communicating a random password to the administrator? placing it in a file would be less of an issue, and i'm not as opposed Storing it in a file also has the advantage that it's less likely to get lost. - Storing passwords even read-only by root is a security weakness as somebody who got root on a server by whatever means normally *still* does not know plaintext passwords which most admins tend to use for several hosts... - Debconf seems to have a way of storing passwords in a secure way, I have a passwords file in /var/lib/debconf - Asking for passwords complicates automated installs so autogen one at least if debconf is not run interactively. - Maybe store the password in /etc/mysql/ *but* warn on every cron.daily run that leaving this file there is a bad idea... -ch- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
hi olaf, On Sat, May 13, 2006 at 10:59:34AM +0200, Olaf van der Spek wrote: What's the status of this bug? given that (a) there wasn't a clear consensus on the ultimate solution and (b) it is not very high on my priority list, i haven't spent any more time with it lately. Could you duplicate it to the 5.0 package? yes, and so could you :) sean -- signature.asc Description: Digital signature
Bug#316127: Status?
sean finney wrote: hi olaf, On Sat, May 13, 2006 at 10:59:34AM +0200, Olaf van der Spek wrote: What's the status of this bug? given that (a) there wasn't a clear consensus on the ultimate solution and (b) it is not very high on my priority list, i haven't spent any more time with it lately. Do you think it's worth to discuss about the various options? Could you duplicate it to the 5.0 package? yes, and so could you :) I don't know the syntax for that off the top of my head. :) But I'll do it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
On Sun, May 14, 2006 at 06:19:29PM +0200, Olaf van der Spek wrote:
given that (a) there wasn't a clear consensus on the ultimate
solution and (b) it is not very high on my priority list, i
haven't spent any more time with it lately.
Do you think it's worth to discuss about the various options?
sure, i happen to have some free time for debian this week, being in
oaxtapec and everything :)
iirc, we left off with three proposals, which involved:
1 - nothing, stay with the status quo
2 - set a random password
3 - set an admin defined password
my order of preference is { 3 , 1 , 2 }. for reasons i think are
outlined in the bug's history.
sean
--
signature.asc
Description: Digital signature
Bug#316127: Status?
sean finney wrote:
On Sun, May 14, 2006 at 06:19:29PM +0200, Olaf van der Spek wrote:
given that (a) there wasn't a clear consensus on the ultimate
solution and (b) it is not very high on my priority list, i
haven't spent any more time with it lately.
Do you think it's worth to discuss about the various options?
sure, i happen to have some free time for debian this week, being in
oaxtapec and everything :)
iirc, we left off with three proposals, which involved:
1 - nothing, stay with the status quo
2 - set a random password
3 - set an admin defined password
my order of preference is { 3 , 1 , 2 }. for reasons i think are
outlined in the bug's history.
I can't find the reasons that are still left. Could you please briefly
repeat the reasons for preferring 3 over 1 and 1 over 2?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
sean finney wrote:
hi olaf,
On Sun, May 14, 2006 at 07:26:54PM +0200, Olaf van der Spek wrote:
1 - nothing, stay with the status quo
2 - set a random password
3 - set an admin defined password
my order of preference is { 3 , 1 , 2 }. for reasons i think are
outlined in the bug's history.
I can't find the reasons that are still left. Could you please briefly
repeat the reasons for preferring 3 over 1 and 1 over 2?
sure:
2:
i don't like the idea of setting a random password arbitrarily because
it could lead to confusion, especially for existing installations.
Only doing it for new installations is enough IMO.
If a notification is send via debconf/email, it'd only lead to confusion
if the administrator doesn't read his email.
furthermore, i don't like the idea of putting a mysql adm password in a
file or otherwise communicating it to the admin on general principle.
It's a bit hard to argue against 'general principle'.
1:
i'm kind of ambivalent towards the current situation. or, i don't like
it, but i'm not that unhappy.
It'd indeed not a release critical issue. :)
3:
i like the idea of prompting the admin for a password, but only in a way
that won't be be annoying. that is, it shouldn't ask the admin if
the password is already set, and it shouldn't ask the admin every time.
Sounds reasonable, but isn't possible depending on debconf priority level.
It also introduces additional questions which is not an advantage on
general principle, especially if it can be avoided. :)
What if the question doesn't get asked?
If you choose to go with 3, I'd prefer a fallback to 2, not to 1.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
hi olaf,
On Sun, May 14, 2006 at 07:26:54PM +0200, Olaf van der Spek wrote:
1 - nothing, stay with the status quo
2 - set a random password
3 - set an admin defined password
my order of preference is { 3 , 1 , 2 }. for reasons i think are
outlined in the bug's history.
I can't find the reasons that are still left. Could you please briefly
repeat the reasons for preferring 3 over 1 and 1 over 2?
sure:
2:
i don't like the idea of setting a random password arbitrarily because
it could lead to confusion, especially for existing installations.
furthermore, i don't like the idea of putting a mysql adm password in a
file or otherwise communicating it to the admin on general principle.
1:
i'm kind of ambivalent towards the current situation. or, i don't like
it, but i'm not that unhappy.
3:
i like the idea of prompting the admin for a password, but only in a way
that won't be be annoying. that is, it shouldn't ask the admin if
the password is already set, and it shouldn't ask the admin every time.
sean
--
signature.asc
Description: Digital signature
Bug#316127: Status?
On Sun, May 14, 2006 at 09:06:23PM +0200, Olaf van der Spek wrote: i don't like the idea of setting a random password arbitrarily because it could lead to confusion, especially for existing installations. Only doing it for new installations is enough IMO. okay. furthermore, i don't like the idea of putting a mysql adm password in a file or otherwise communicating it to the admin on general principle. It's a bit hard to argue against 'general principle'. fair enough :) i like the idea of prompting the admin for a password, but only in a way that won't be be annoying. that is, it shouldn't ask the admin if the password is already set, and it shouldn't ask the admin every time. Sounds reasonable, but isn't possible depending on debconf priority level. It also introduces additional questions which is not an advantage on general principle, especially if it can be avoided. :) What if the question doesn't get asked? if the admin does not provide a password (by either answering blank or because of not even seeing the question), then no action is taken, and we have the same situation as we do now. the reason why iwouldn't want to fall back to a random password is that it's possible that the admin doesn't want a password set, and it would be nice if we could respect that. of course, we could also maybe make a special exception for if the admin chooses random as the password, and set it randomly then, but then that would not get most of the benefits you want i suppose. sean -- signature.asc Description: Digital signature
Bug#316127: Status?
sean finney wrote: furthermore, i don't like the idea of putting a mysql adm password in a file or otherwise communicating it to the admin on general principle. It's a bit hard to argue against 'general principle'. fair enough :) So could you please explain what part of your 'general principle' is against communicating a random password to the administrator? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316127: Status?
hi olaf, On Sun, May 14, 2006 at 10:20:55PM +0200, Olaf van der Spek wrote: So could you please explain what part of your 'general principle' is against communicating a random password to the administrator? if it's done via debconf it will be world-readable (though actions could be taken to reduce that window of time by deleting the prompt afterwards. and the systems-administrator in me would scream at the idea of putting it in an email, which is where it could end up if the admin does not see the debconf note. placing it in a file would be less of an issue, and i'm not as opposed to that, but i think i still like prompting the admin for a real password and not storing it anywhere. sean -- signature.asc Description: Digital signature
Bug#316127: Status?
Hi, What's the status of this bug? Could you duplicate it to the 5.0 package? Greetings, Olaf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
