File Permissions
 

I'm writing a simple installer and I'm stumped
on how to create user accounts.

How cant I create root account without first being root?


This installer is made only in C++.

Thanks for your help!

Impossible, hopefully - it would be a major security breach.

I know it's not possible.
My question is what can
I do to get a root password
from the user during the install
process?

Thanks for the quick reply.

Don't...

The usual solution is to start sudo with the command you want processed.

Sudo will then prompt for the appropriate password if the user is authorized...

If you are using a GUI there are a couple of GUI versions that accomplish the same thing.

The reason you don't is that there is NO reason for the user to trust your installer beyond what it should be doing. There is no reason for it to HAVE the root password, as you may have a trojan that passes the root password off to someone else...

There are no authorized users because
we are in the install process.
This "catch-22" is almost breaking
my will.

If the admins are installing the system, they are the ones to set it up.

Not you. You DO get to tell them to configure it. But it is up to the site policy as to who gets to do what to the system. And passing the root password around is not a proper security policy.

Now if you are writing a system installer, then your installer is ALREADY root. But most of those are NOT written in C++. They are frequently done in Python, or shell scripts.

Thank you. I am writing a system installer.
I'm thinking about the Anaconda installer.
During the install process
the installer asks for a user generated
password for the root account.

I would just like to take that input
and finish installing a custom distro.

I am most comfortable in C++. I'm aware
of the runtime support needed to get
things going.
Thanks for your help!

It is much more flexible to use one already written - such as Anaconda.

Installation tools are quite large, and have to handle a number of complex subjects. That was why Anaconda is written in Python.

And it is possible to do a custom distribution with Anaconda - it usually called a "spin", and there are tools available that make it realatively easy to do.

http://fedoraproject.org/wiki/How_to...fedora_desktop

they are complex, but the subjects that they handle are simple

unpack all the packages
set up language, time, etc
what else ?

anaconda is very complex, not recommended playing around with

keyboard setup,
display setup,
disk partitioning,
identifying the target to install on (partition/lvm/mdadm + partitioning)
identifying the source to retrieve the packages from (URL/net? disk? USB? NFS?) and setup,
package selection (assuming there IS a choice).
filesystem to use (xfs,ext4,btrfs,other?)
boot configuration and initialization,
mount configuration (fstab setup mostly),
swap configuration and initialization,

Of course, if all of this is supposed to be done, then you aren't doing an installation, but something closer to just cloning a disk...

In which case all you do is install the finished clone.

Anaconda is rather complex because it is trying to do something that IS complex.

Thank you all for your response.

I am not interested in spinning
a distro with Anaconda. I have
written the installer already.
Minus the "root problem".

I just need some kind of way
to get around this "catch-22".

Once again, thanks!

(I might end up using Anaconda
but the question on how to solve
this problem will eat at me)

Then look at how Anaconda solves it.

Right on!
I'm just thinking that the solution will
be Python specific but I'll
comb the source.

Thanks!

No. It can't be specific. The technique is not that complicated.

Another place to look would be in the passwd utility. It does the same thing.

Now one thing that MAY be a problem is that during the initial install, the terminals are NOT configured. You have to do that if you are using a terminal interface. If you are using a GUI, then Anaconda is quite reasonable to look at, as it uses the same GUI libraries that you would likely be using.

Thanks jpollard. You and everyone in this post
have been very accommodating.

Cheers, friend. I'll come back to
this post and report later this evening.

Once again, thanks!

true, partitioning

unpacking includes target
source is easy, even internet ones
package selection is easy, also more of a gui thing (gui was not mentioned)
filesystem goes into partitioning
boot config is easy since you have all the data you need to do it
fstab (that includes swap) is easy when you do partitioning

i'm against using anaconda as an example as apparently it is so incredibly complex that very competent programmers can't rid it of bugs

slackwares installer is much much simpler and does it all except the partitioning part
(a gui version of it is a matter of making a gui more then anything else)
k, it doesn't do encryption and lvm

depends on the configuration of the LVM/partitioning. Anaconda is complex, as it is trying to do the whole install/configuration/configuration tasks. It has to be complex. That is one of the nice things about Slakware - it doesn't try to do everything. But then, the person installing has to know more.

In the case of btrfs, there are storage pools to be considered which can be one or more disks/partitions.

In the case of xfs/ext4 there are optimization configurations...

As far as not using something that has already been done..
Up to you. NIH exists in lots of forms.

Boot configuration depends on what you are dealing with - BIOS/UEFI, grub/grub2/lilo/elilo... and then there are signing issues for secureboot, unless that is disabled...

Lots of variables and combinations.

Slackware is much simpler in packaging too. But it depends on what you are doing. It is considered more complex since it doesn't directly deal with dependency lists...

When you're installing an OS, you have to be root user because you are creating partitions, file systems, etc. Or to be more precise, there's no users (other than the 'implicit root') at that time.

Just to add to what NevemTeve has written. The reason an installer requests a password is not to become root, since you already are root to do the install, but to add the password to the password file.

This is turning into much larger affair

Are you making a Linux installer or an application/applet/etc installer. If it is Linux installer, the installer is running in a live environment and the root account is created on the partition the will contains the new /etc/ and as such it can be created with a password that supplied by the "installing person" via the fact that you are root in the installer or that you are a user that can do su or sudo commands.

That is what happens with a system level installer. There are a LOT details to get right.

That is why people usually reuse existing installers.

Thank you all.

I had a derp moment!

This is what I learned:

The initramfs is unpacked
and therefore in kernel space.
Which in turn gives you
"automatic admin" rights.

OS-installation is always happening in admin mode, initramfs notwithstanding (packed or otherwise).
Mind you, the installer program isn't part of the kernel.

Right on!

Just to clarify:
The initial initramfs in the root of
the .iso will start up my installer.
I will use dracut at the end of the
install to make another initramfs on
the HD

Thaks all for your help.

Linux and the LQ forum have been
very good to me!