RFC: writing kernel cmdline options to grub.conf for dracut

RFC: writing kernel cmdline options to grub.conf for dracut

[Hans de Goede]

Hi,

This morning I've been talking to Harald Hoyer about what sort
of commandline options dracut will be needing to find the /
filesystem beside root=UUID=1234567890 .

In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt)
root=UUID=1234567890 should suffice.

However in certain cases for example dracut will need additional
info to find the disks.

We've come to the following plan for iscsi targets:
1) Extend the dhcp_root dhcp variable iscsi syntax to
    be able include a username password, so:
    iscsi:192.168.50.2::::iqn.2009-06.dracut:target66
    Can become:
    iscsi:user:pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66
    Or:
    iscsi:user:pass:reverse_user:reverse_pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66

2) Pass root-path=iscsi:... on the kernel cmdline, for each needed iscsi target, so if
    necessary this will be passed multiple times, dracut will be modified to be able
    handle multiple root-path arguments being passed in

3) chmod /proc/cmdline 400, so that it cannot be read by ordinary users, plugging
    the passwork leak problem

Now the remaining question is how to implement the adding of the needed
cmdline options to grub.conf.

For the iscsi case (and atleast fcoe will be similar) I see the following 2 options,
both of which are feasible:
1) Add code to iscsi.py to get the needed cmdline options

2) Add a dracutCmdlineOptions property to all Device classes, which will return
    the needed options (if any) to make the device in question available inside
    dracut.

One of the issues here is that onlining an iscsi target, may get us multiple disks
as the target may have multiple LUN's. If more then one LUN of the same target
is needed we might end up with having the same root-path=iscsi:... option twice on
the cmdline, filtering this will be is easy though so this is not really an issue.

Looking at this from the iscsi pov, doing this from iscsi.py is easier, as
that already has a list of targets instead of a list of disks (so LUN's) as the
rest of the storage code has. Looking at this from the pov of the rest of
the code it might be cleaner in the long run to make this a device property though.

So I'm not sure what to do, advice is / ideas are very welcome ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: writing kernel cmdline options to grub.conf for dracut

[Seewer Philippe]

Hans de Goede wrote:
> Hi,
> 
> This morning I've been talking to Harald Hoyer about what sort
> of commandline options dracut will be needing to find the /
> filesystem beside root=UUID=1234567890 .
> 
> In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt)
> root=UUID=1234567890 should suffice.
> 
> However in certain cases for example dracut will need additional
> info to find the disks.
> 
> We've come to the following plan for iscsi targets:
> 1) Extend the dhcp_root dhcp variable iscsi syntax to
>    be able include a username password, so:
>    iscsi:192.168.50.2::::iqn.2009-06.dracut:target66
>    Can become:
>    iscsi:user:pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66
>    Or:
>    
> iscsi:user:pass:reverse_user:reverse_pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66 
> 
> 
> 2) Pass root-path=iscsi:... on the kernel cmdline, for each needed iscsi 
> target, so if
>    necessary this will be passed multiple times, dracut will be modified 
> to be able
>    handle multiple root-path arguments being passed in
> 
> 3) chmod /proc/cmdline 400, so that it cannot be read by ordinary users, 
> plugging
>    the passwork leak problem

This does not really plug the leak. Just boot until initramfs is loaded, 
pull the network plug and wait until dracut drops us to a (root-)shell.

> 
> Now the remaining question is how to implement the adding of the needed
> cmdline options to grub.conf.

Question: Is it really necessary to provide username/password to dracut? 
Wouldn't it be better to ask the user? I mean if a mount is password 
protected, be it cryptroot, nfs4 or whatever, shouldn't the user enter 
the data?

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: writing kernel cmdline options to grub.conf for dracut

[Harald Hoyer]

On 07/02/2009 04:18 PM, Seewer Philippe wrote:
> Hans de Goede wrote:
>> 3) chmod /proc/cmdline 400, so that it cannot be read by ordinary
>> users, plugging
>> the passwork leak problem
>
> This does not really plug the leak. Just boot until initramfs is loaded,
> pull the network plug and wait until dracut drops us to a (root-)shell.

Ah, which reminds me, that we should have an option to turn that off.

>
>>
>> Now the remaining question is how to implement the adding of the needed
>> cmdline options to grub.conf.
>
> Question: Is it really necessary to provide username/password to dracut?
> Wouldn't it be better to ask the user? I mean if a mount is password
> protected, be it cryptroot, nfs4 or whatever, shouldn't the user enter
> the data?
>

username/password for iSCSI disks entered by a normal user every day he boots 
his diskless client?

Re: RFC: writing kernel cmdline options to grub.conf for dracut

[Hans de Goede]

On 07/02/2009 04:18 PM, Seewer Philippe wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> This morning I've been talking to Harald Hoyer about what sort
>> of commandline options dracut will be needing to find the /
>> filesystem beside root=UUID=1234567890 .
>>
>> In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt)
>> root=UUID=1234567890 should suffice.
>>
>> However in certain cases for example dracut will need additional
>> info to find the disks.
>>
>> We've come to the following plan for iscsi targets:
>> 1) Extend the dhcp_root dhcp variable iscsi syntax to
>> be able include a username password, so:
>> iscsi:192.168.50.2::::iqn.2009-06.dracut:target66
>> Can become:
>> iscsi:user:pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66
>> Or:
>> iscsi:user:pass:reverse_user:reverse_pass-Q0ErXNX1RuYrv4yRHWfJZg@public.gmane.org::::iqn.2009-06.dracut:target66
>>
>>
>> 2) Pass root-path=iscsi:... on the kernel cmdline, for each needed
>> iscsi target, so if
>> necessary this will be passed multiple times, dracut will be modified
>> to be able
>> handle multiple root-path arguments being passed in
>>
>> 3) chmod /proc/cmdline 400, so that it cannot be read by ordinary
>> users, plugging
>> the passwork leak problem
>
> This does not really plug the leak. Just boot until initramfs is loaded,
> pull the network plug and wait until dracut drops us to a (root-)shell.
>

If a user has physical access to the machine, and the passwords are not encrypted
with some key which has to be entered manually (which would be really awkward for
say a headless server in a datacenter booting from an iSCSI SAN LUN) you've already
lost.

>>
>> Now the remaining question is how to implement the adding of the needed
>> cmdline options to grub.conf.
>
> Question: Is it really necessary to provide username/password to dracut?

Yes, in the case of machines booting of iSCSI it is, this is not a passphrase
for encryption, this is authentication information to connect to an iSCSI target
(one or more disks).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html