| Summary: | localmount implicitly runs "mount -a" whenever a dependant service is started | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Walter Dnes <waltdnes> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | openrc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Walter Dnes
2016-04-14 00:45:13 UTC
(In reply to Walter Dnes from comment #0) > Let's say that the admin has, in /etc/sudoers.d, allowed the user to start > gpm (text-console mouse) or some other innocent-looking service... I think the assumption that if you grant "gpm start" you only ever get gpm to start is wrong. OpenRC starts services that gpm needs beforehand. As your localmount start during boot failed, it will try to correct that to fulfill the service dependency. I'd guess -D/--nodeps helps if that behavior is undesirable. CC'ing OpenRC maintainers to give them a chance to comment. Unless they see an issue here, I'll close the bug. Further experimentation shows that gpm and net.eth0 (and who knows what else) will not start if "mount -a" does not fully succeed. I don't see the "logic" behind requiring a successful "mount -a" in order to start gpm or net.eth0 in the first place. Maybe I should report this as a different type of bug for gpm or net.eth0? "mount -a" is always run on boot-up by localmount in order to attempt to mount everything in /etc/fstab. In your case it is simply retrying because it did not succeed the first time. If you want the drive in question to only be auto-mounted with "mount -a" at boot-up, consider adding the "nofail" option to fstab. If something prevents the drive from mounting at boot (e.g. it's not connected) the localmount service will still start successfully. Because the service has started, you will not see "Mounting local filesystems" when starting other services. If you don't want the drive to be mounted at boot-up either, consider adding "noauto" instead. This should still allow "mount /mnt/drive0" to work but it will be excluded from "mount -a". I'm not a developer (just stumbled across this during a search) but I don't think there is a bug here. gpm and other services expect localmount to complete successfully on boot-up, as it could be expecting a separate /var or /usr partition to be mounted. Anything non-critical should have nofail or noauto added. More experimentation... If /etc/fstab asks for a non-existant drive on an existing mountpoint, then "nofail" works as advertised, *BUT* it does not help if the mountpoint doesn't exist. Example; with /etc/fstab /dev/sda1 / ext3 noatime,nodiratime,async 0 1 /dev/sda2 none swap sw 0 0 /dev/sdb1 /mnt/drive0/ auto noatime,nodiratime,async,nofail,exec 0 2 /dev/sdc1 /mnt/drive1/ auto noatime,nodiratime,async,nofail,exec 0 2 /dev/sdd1 /mnt/drive2/ auto noatime,nodiratime,async,nofail,exec 0 2 Rename "/mnt/drive2" to "/mnt/drive22" and reboot. Look Ma, no net.eth0 or gpm. And when I try "/etc/init.d/gpm start", I get... * Mounting local filesystems ...mount: mount point /mnt/drive2/ does not exist * Some local filesystem failed to mount [ !! ] * ERROR: localmount failed to start * ERROR: cannot start gpm as localmount would not start Yes, *WITH NOFAIL*!!! Anyhow, I think I've come up with a workaround that actually works. Start with /etc/fstab /dev/sda1 / ext3 noatime,nodiratime,async 0 1 /dev/sda2 none swap sw 0 0 /dev/sdb1 /mnt/drive0/ auto noatime,nodiratime,async,noauto,exec 0 2 /dev/sdc1 /mnt/drive1/ auto noatime,nodiratime,async,noauto,exec 0 2 /dev/sdd1 /mnt/drive2/ auto noatime,nodiratime,async,noauto,exec 0 2 And an *EXECUTABLE* file, "etc/local.d/000" containing... #!/bin/bash mount /dev/sdb1 mount /dev/sdc1 mount /dev/sdd1 This can fail without taking down gpm, networking, etc, with it. |
