Regression Mounting /proc w/ kernel 3.4.0 - "uid" parameter no longer ignored.

From: Eric W. Biederman
Date: Fri May 25 2012 - 16:19:34 EST


kd6lvw@xxxxxxxxx writes:

> --- On Thu, 5/24/12, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>> "D. Stussy" <spam+newsgroups@xxxxxxxxxxxxxxxx> writes:
>> > proc:Â unrecognized mount option "uid=1" or missing value
>> >
>> > This works under 3.3.6 and earlier (I never tried 3.3.7). It appears that the
>> > "uid" mount option was removed. WHY? More importantly, where is this change
>> > listed? I didn't see it in the git log.
>> >
>> > This is really bad as I rebooted a remotely colocated server and since the
>> > procfs is not mounted, I cannot log in via SSH to correct the problem.
>> >
>> > OK, so there's not that much point in changing the UID of the procfs files, but
>> > I preferred to set their default ownership to a non-privileged user.
>>
>> There has never been a uid= option to /proc in Linus's tree. I believe
>> if you look you will find this feature was from a patch (perhaps from
>> your distro) that added that support.
>
> I compile both the util-linux-ng and the kernel from source. There is no distribution patch involved. As noted, kernel version 3.3.6 didn't bitch about the setting, while 3.4.0 does and won't mount procfs.
>
> From the man page (copy at "http://linux.die.net/man/8/mount";):
>
> "Mount options for proc
>
> Â ÂÂÂ"uid=value and gid=value
>
> "These options are recognized, but have no effect as far as I can see."
>
>
> Removal of this compatibility should have been noted. WHERE was it
> noted? Linux.die.net is a distribution independent documentation
> site. It might not do anything, but per mount's documentation, it is
> acceptable.

The only possible change to /proc that could have cause this behavior
between 3.3 and 3.4 is below.

Not ignoring options seems to be a regression that has affected your
setup on 3.4.

My gut feel is that we should revert all of the /proc option parsing
code as it is ugly code and apparently it could not have been used
before 3.4 so no one can be depending on it. But I just want an excuse
to get rid of ugly code. Accepting that /proc ignores all options
passed ot it as part of the ABI and not being able to add any options
to /proc ever is also a pretty horrible state to be in.

Shrug I will let you and the parties involved in creating this
regression figure this out.

Eric

ommit 99663be772c827b8f5f594fe87eb4807be1994e5
Author: Vasiliy Kulikov <segoon@xxxxxxxxxxxx>
Date: Thu Apr 5 14:25:04 2012 -0700

proc: fix mount -t proc -o AAA

The proc_parse_options() call from proc_mount() runs only once at boot
time. So on any later mount attempt, any mount options are ignored
because ->s_root is already initialized.

As a consequence, "mount -o <options>" will ignore the options. The
only way to change mount options is "mount -o remount,<options>".

To fix this, parse the mount options unconditionally.

Signed-off-by: Vasiliy Kulikov <segoon@xxxxxxxxxxxx>
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@xxxxxxxxx>
Tested-by: Arkadiusz Miskiewicz <a.miskiewicz@xxxxxxxxx>
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>
Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Cc: Valdis Kletnieks <Valdis.Kletnieks@xxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

diff --git a/fs/proc/root.c b/fs/proc/root.c
index 46a15d8..eed44bf 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -115,12 +115,13 @@ static struct dentry *proc_mount(struct file_system_type *fs_type,
if (IS_ERR(sb))
return ERR_CAST(sb);

+ if (!proc_parse_options(options, ns)) {
+ deactivate_locked_super(sb);
+ return ERR_PTR(-EINVAL);
+ }
+
if (!sb->s_root) {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/