From: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Alastair Scobie <ascobie-5WhEfG1TI8k@public.gmane.org>
Cc: "initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Dracut and root filesystem UUIDs
Date: Fri, 13 Jan 2012 16:08:45 +0100 [thread overview]
Message-ID: <4F1048FD.20702@redhat.com> (raw)
In-Reply-To: <4F103EB1.9000209-5WhEfG1TI8k@public.gmane.org>
On 13.01.2012 15:24, Alastair Scobie wrote:
> On 13/01/2012 14:09, Harald Hoyer wrote:
>> On 13.01.2012 15:06, Harald Hoyer wrote:
>>> On 13.01.2012 12:55, Alastair Scobie wrote:
>>>> Apologies if this is the incorrect mailing list to discuss this issue..
>>>>
>>>> Does anyone know if there is a way to configure dracut such that
>>>> it will not attempt to mount USB mass-storage devices at boot time,
>>>> but will still allow mounting of such devices once a system (in our
>>>> case ScientifcLinux6) is fully booted?
>>>>
>>>> Why do we want to do this? We run several large teaching labs running
>>>> SL6 desktops. We mount filesystems by UUID. We are concerned that our
>>>> students could install a USB memory stick, at boot time, with a
>>>> filesystem with the same UUID as the "official" root filesystem so
>>>> fooling dracut into mounting a trojan filesystem.
>>>>
>>>> Thanks, in advance, for any ideas..
>>>>
>>>> Alastair Scobie
>>>>
>>>>
>>>
>>> specifying "root=UUID=<uuid> rd.shell=0" will do exactly what you want. Then you
>>> also want to secure grub (or any other bootloader) with a password.
>>
>> Ah, sorry, only read half of it. You might want to blacklist the USB storage
>> kernel driver then.
>>
>> "rd.driver.blacklist=usb-storage"
>
> Would that blacklist apply only during dracut - would the usb-storage
> module still be loadable if a user inserted a USB stick after login? ...
it would only be blacklisted during dracut
>
>> or choose one of the by-path symlinks with e.g.
>> "root=/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1"
>
> ... otherwise, this looks like the best approach.
>
> Thanks
>
>
>
>
>
prev parent reply other threads:[~2012-01-13 15:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 11:55 Dracut and root filesystem UUIDs Alastair Scobie
[not found] ` <4F101BA1.5000903-5WhEfG1TI8k@public.gmane.org>
2012-01-13 14:06 ` Harald Hoyer
[not found] ` <4F103A61.1070907-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-01-13 14:09 ` Harald Hoyer
[not found] ` <4F103B21.80206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-01-13 14:24 ` Alastair Scobie
[not found] ` <4F103EB1.9000209-5WhEfG1TI8k@public.gmane.org>
2012-01-13 15:08 ` Harald Hoyer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1048FD.20702@redhat.com \
--to=harald-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=ascobie-5WhEfG1TI8k@public.gmane.org \
--cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.