=== mcasadevall is now known as NCommander === kung|away is now known as kung === kung is now known as kung|away [14:29] hi all [14:29] does anyone here know how to generate a SHA512 password with php that will be accepted by ubuntu? [14:32] dijenerate: What are you trying to do? More context may help get an answer. [14:37] persia: we have a custom linux based on ubuntu mobile where the first time user setup is done via a web page [14:37] So on first boot, a browser is launched to a local server executing PHP? [14:37] persia: exactly [14:38] persia: so the problem is, I can currently generate a DES password without a problem [14:38] Can't you just use http://php.net/manual/en/function.system.php ? [14:38] persia: looking... 1 sec [14:39] Yes, you'd have to do some privilege escalation, but you get to use the normal tools (e.g. adduser) [14:39] Err, maybe useradd would be better. Hrm. [14:40] * persia always gets confused between those two [14:41] persia: actually I'm using shell_exec() and have no problems getting the commands executed [14:41] So why do you need to manually construct the hashed password? [14:42] Can't you just get a value from the user (or generate one and tell the user), and then use useradd or passwd to generate the hash? [14:42] persia: If I use usr/sbin/useradd username -p encodedpassword the password would have to already be encoded [14:42] persia: I don't have mkpasswd installed at the moment [14:43] persia: the packages that carry that aren't needed for anything else so they were stripped [14:43] Do you have `passwd` installed? [14:43] (if you have useradd, you probably do) [14:43] persia: I do but won't that run as www-data? [14:44] persia: it needs to be run as the newly created user [14:44] Like I said, you'd have some privilege escalation to do. [14:44] But I don't see how the hash would help you if you're running as www-data anyway. [14:44] persia: during first boot www-data has sudo privileges anyway [14:44] (because you can't write /etc/shadow as www-data, or if you can, other things are wrong) [14:45] Then just run it in a root context. [14:45] Just after the user is created. [14:45] persia: so it can run /usr/sbin/useradd [14:46] persia: passwd.. ok looking at the man page for it now [14:46] persia: I was under the impression it could only be run for the user that calls it [14:47] Or as root for arbitrary logins. That's to support the "Hi. I forgot my password.", "OK. I've just set it to 'k23jn4#(', please try logging in again" use case. [14:48] so, for example, one can run `sudo passwd ubuntu` to change the password for the ubuntu user. [14:48] persia: of course what ever I use cannot be interactive, it needs to be executable in one line [14:48] Well, kinda. [14:48] You need to be able to call some executable that does the right thing, given a set of arguments. [14:49] persia: right so I'm looking for the passwd arguments that will allow me to place the password in plaintext inline [14:49] Or with some given standard input ($proc=proc_open ...) [14:49] But the thing you execute can be a script that mitigates interactivity. [14:50] You might be able to crib something from http://bazaar.launchpad.net/~ubuntu-core-dev/user-setup/ubuntu/annotate/head:/user-setup-apply (part of the Ubuntu installer) [14:50] persia: actually useradd with no password followed by chpasswd may work [14:51] Looks like that is using chpasswd or usermod. [14:51] persia: 1 sec brb [14:53] Another option would be to set the initial password to nothing an expired, but this only works if you generally don't have internet connectivity during initial setup. [15:16] persia: found the solution... /usr/sbin/useradd username [15:16] persia: followed by echo 'username:password' | /usr/sbin/chpasswd -c SHA512 [15:16] persia: works perfectly [15:17] persia: I have an auto-install script that generates my new installation on virgin hardware from a tarball [15:17] dijenerate: I'll recommend you not do it that way. [15:17] persia: and I just need to get it to be auto run from a ubuntu server live usb image [15:17] If you look in the comments on the php system() call page, there's an example of using PHP to feed STDIN [15:18] If you use echo, it shows in the process listing, which may result in information leakage. [15:18] Not that it's likely someone else can run ps at this point, but still. [15:18] persia: it's local and internal [15:18] Are your kiosks not going to end-users? Just for internal use? [15:18] persia: so the user just sees a pretty web page and won't know what goes on beneath [15:18] * persia misunderstood the product target [15:19] persia: end users but the php permission change after the first time set up [15:19] persia: and there is no virtual console available [15:19] persia: or recovery menu option in grub [15:19] Let me put this another way: you don't want someone to get your device, and hack it, and then complain about exposing the password. [15:20] persia: so the only access is direct to the drive from another boot session [15:20] If you use php to feed STDIN, you're still passing plaintext, but not somewhere where it's shown in system accounting. [15:20] persia: if they hack their system, our server won't speak to it [15:20] persia: these are just dumb terminals [15:21] Oh, so the account is being set up on a central server based on the client access? [15:21] persia: yes [15:21] I thought it was a local account. [15:21] persia: the same account exists locally for the browser session to run after [15:22] persia: but that's just so the usernames match [15:22] If you're doing distributed authentication, then it's even more important that you don't use echo, because otherwise you don't have deniability that your system administrators can know the user passwords. [15:22] persia: the passwords expire on the server every 30 days or more frequently for higher security accounts [15:23] OK. You know your constraints better than I. If you don't want to expose it, the code is referenced above :) [15:23] persia: the terminals keep the same password since it's not needed for anything other than the browser session [15:24] persia: I understand your points and thanks but we have decided that the best security practice is to never have the server account and the local account match passwords [15:25] I agree with that practice. I'm just not convinced it's complete :) [15:25] But it's not worth either of our time to fuss about it :) [15:26] persia: lol [17:36] hi again... I'm trying to create a bootable ubuntu stick that boots a live cd image but without X11 etc, I want to boot directly to console [17:36] I have made a bootable stick in the past so my main concern is which iso to use and how to go about modifying it [17:37] so I can strip X and just have hotplug for network and standard utils like ntpdate, mkfs.ext4 and fdisk and necessary on top of a base install [17:38] sorry... should have read... as necessary [17:39] from the shell I'd like to be able to access a partition on the same stick so I'd like to be able to alter the start-up config of the live image and it's menu [17:40] oh, anyone know if it's possible to have a dual booting stick with a live image on one side and DOS on the other, or even if it's possible to add [17:41] DOS as an option to the live disk/stick's menu? [17:41] it's needed to run a bios flashing utility [17:41] anybody alive in here? [17:53] I guess not... [17:53] sigh... === asac_ is now known as asac === kung|away is now known as kung === kung is now known as kung|away === mcasadevall is now known as NCommander