[14:29] <dijenerate> hi all
[14:29] <dijenerate> does anyone here know how to generate a SHA512 password with php that will be accepted by ubuntu?
[14:32] <persia> dijenerate: What are you trying to do?  More context may help get an answer.
[14:37] <dijenerate> persia: we have a custom linux based on ubuntu mobile where the first time user setup is done via a web page
[14:37] <persia> So on first boot, a browser is launched to a local server executing PHP?
[14:37] <dijenerate> persia: exactly
[14:38] <dijenerate> persia: so the problem is, I can currently generate a DES password without a problem
[14:38] <persia> Can't you just use http://php.net/manual/en/function.system.php ?
[14:38] <dijenerate> persia: looking... 1 sec
[14:39] <persia> Yes, you'd have to do some privilege escalation, but you get to use the normal tools (e.g. adduser)
[14:39] <persia> Err, maybe useradd would be better.  Hrm.
[14:40]  * persia always gets confused between those two
[14:41] <dijenerate> persia: actually I'm using shell_exec() and have no problems getting the commands executed
[14:41] <persia> So why do you need to manually construct the hashed password?
[14:42] <persia> 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] <dijenerate> persia: If I use  usr/sbin/useradd username -p encodedpassword the password would have to already be encoded
[14:42] <dijenerate> persia: I don't have mkpasswd installed at the moment
[14:43] <dijenerate> persia: the packages that carry that aren't needed for anything else so they were stripped
[14:43] <persia> Do you have `passwd` installed?
[14:43] <persia> (if you have useradd, you probably do)
[14:43] <dijenerate> persia: I do but won't that run as www-data?
[14:44] <dijenerate> persia: it needs to be run as the newly created user
[14:44] <persia> Like I said, you'd have some privilege escalation to do.
[14:44] <persia> But I don't see how the hash would help you if you're running as www-data anyway.
[14:44] <dijenerate> persia: during first boot www-data has sudo privileges anyway
[14:44] <persia> (because you can't write /etc/shadow as www-data, or if you can, other things are wrong)
[14:45] <persia> Then just run it in a root context.
[14:45] <persia> Just after the user is created.
[14:45] <dijenerate> persia: so it can run /usr/sbin/useradd
[14:46] <dijenerate> persia: passwd.. ok looking at the man page for it now
[14:46] <dijenerate> persia: I was under the impression it could only be run for the user that calls it
[14:47] <persia> 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] <persia> so, for example, one can run `sudo passwd ubuntu` to change the password for the ubuntu user.
[14:48] <dijenerate> persia: of course what ever I use cannot be interactive, it needs to be executable in one line
[14:48] <persia> Well, kinda.
[14:48] <persia> You need to be able to call some executable that does the right thing, given a set of arguments.
[14:49] <dijenerate> persia: right so I'm looking for the passwd arguments that will allow me to place the password in plaintext inline
[14:49] <persia> Or with some given standard input ($proc=proc_open ...)
[14:49] <persia> But the thing you execute can be a script that mitigates interactivity.
[14:50] <persia> 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] <dijenerate> persia: actually useradd with no password followed by chpasswd may work
[14:51] <persia> Looks like that is using chpasswd or usermod.
[14:51] <dijenerate> persia: 1 sec brb
[14:53] <persia> 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] <dijenerate> persia: found the solution... /usr/sbin/useradd username
[15:16] <dijenerate> persia: followed by  echo 'username:password' | /usr/sbin/chpasswd -c SHA512
[15:16] <dijenerate> persia: works perfectly
[15:17] <dijenerate> persia: I have an auto-install script that generates my new installation on virgin hardware from a tarball
[15:17] <persia> dijenerate: I'll recommend you not do it that way.
[15:17] <dijenerate> persia: and I just need to get it to be auto run from a ubuntu server live usb image
[15:17] <persia> If you look in the comments on the php system() call page, there's an example of using PHP to feed STDIN
[15:18] <persia> If you use echo, it shows in the process listing, which may result in information leakage.
[15:18] <persia> Not that it's likely someone else can run ps at this point, but still.
[15:18] <dijenerate> persia: it's local and internal
[15:18] <persia> Are your kiosks not going to end-users?  Just for internal use?
[15:18] <dijenerate> 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] <dijenerate> persia: end users but the php permission change after the first time set up
[15:19] <dijenerate> persia: and there is no virtual console available
[15:19] <dijenerate> persia: or recovery menu option in grub
[15:19] <persia> 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] <dijenerate> persia: so the only access is direct to the drive from another boot session
[15:20] <persia> If you use php to feed STDIN, you're still passing plaintext, but not somewhere where it's shown in system accounting.
[15:20] <dijenerate> persia: if they hack their system, our server won't speak to it
[15:20] <dijenerate> persia: these are just dumb terminals
[15:21] <persia> Oh, so the account is being set up on a central server based on the client access?
[15:21] <dijenerate> persia: yes
[15:21] <persia> I thought it was a local account.
[15:21] <dijenerate> persia: the same account exists locally for the browser session to run after
[15:22] <dijenerate> persia: but that's just so the usernames match
[15:22] <persia> 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] <dijenerate> persia: the passwords expire on the server every 30 days or more frequently for higher security accounts
[15:23] <persia> OK.  You know your constraints better than I.  If you don't want to expose it, the code is referenced above :)
[15:23] <dijenerate> persia: the terminals keep the same password since it's not needed for anything other than the browser session
[15:24] <dijenerate> 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] <persia> I agree with that practice.  I'm just not convinced it's complete :)
[15:25] <persia> But it's not worth either of our time to fuss about it :)
[15:26] <dijenerate> persia: lol
[17:36] <dijenerate> 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] <dijenerate> 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] <dijenerate> 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] <dijenerate> sorry... should have read... as necessary
[17:39] <dijenerate> 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] <dijenerate> 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] <dijenerate> DOS as an option to the live disk/stick's menu?
[17:41] <dijenerate> it's needed to run a bios flashing utility
[17:41] <dijenerate> anybody alive in here?
[17:53] <dijenerate> I guess not...
[17:53] <dijenerate> sigh...