sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Peter T. Breuer]

A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
from using the /proc/sys/ interface:

@@ -1275,7 +1481,9 @@ static void sysctl_set_parent(struct ctl

 static __init int sysctl_init(void)
 {
+       int err;
        sysctl_set_parent(NULL, root_table);
+       err = sysctl_check_table(root_table);
        return 0;
 }
 
and

@@ -1360,6 +1568,10 @@ struct ctl_table_header *register_sysctl
        tmp->used = 0;
        tmp->unregistering = NULL;
        sysctl_set_parent(NULL, table);
+       if (sysctl_check_table(tmp->ctl_table)) {
+               kfree(tmp);
+               return NULL;
+       }
        spin_lock(&sysctl_lock);
        list_add_tail(&tmp->ctl_entry, &root_table_header.ctl_entry);
        spin_unlock(&sysctl_lock);

and IT TURNS OUT THAT (sorry, did I scream?) sysctl_check_table can't
succeed on anything that's now not been hardwired into the core kernel
because of the new sysctl_check.c file  which contains gazzilions of
explict tables aying what is supposed to be in there in excruciating
detail and which are consulted through sysctl_check_table and
sysctl_binary_lookup.  E.g:

static struct trans_ctl_table trans_random_table[] = {
        { RANDOM_POOLSIZE,      "poolsize" },
        { RANDOM_ENTROPY_COUNT, "entropy_avail" },
        { RANDOM_READ_THRESH,   "read_wakeup_threshold" },
        { RANDOM_WRITE_THRESH,  "write_wakeup_threshold" },
        { RANDOM_BOOT_ID,       "boot_id" },
        { RANDOM_UUID,          "uuid" },
        {}
};

It appears to me, not that I am totally sure because of the lack of
comments, that every attempt to add a new direcotry in the tree with
a number that is not listed in the above mess fails through
sysctl_binary_lookup.sysctl_binary_lookup, and every attempt to add
a directory with CTL_UNNUMBERED instead fails if it has children because
the children cry about having an unnumbered parent. Every attempt to
add a directory usurping an existing number fails through some string
mismatch against the trans_.._tables on the dirnames in one of the
numerous lookup functions (forget which).

(somebody has really spent their holidays on this).

What's a person to do? 

Peter

Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Alexey Dobriyan]

On 3/1/08, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
> from using the /proc/sys/ interface:

That's somewhat correct.

> and IT TURNS OUT THAT (sorry, did I scream?)

Nobody gives a.

> sysctl_check_table can't
> succeed on anything that's now not been hardwired into the core kernel
> because of the new sysctl_check.c file which contains gazzilions of
> explict tables aying what is supposed to be in there in excruciating
> detail and which are consulted through sysctl_check_table and
> sysctl_binary_lookup. E.g:
>
> static struct trans_ctl_table trans_random_table[] = {
> { RANDOM_POOLSIZE, "poolsize" },
> { RANDOM_ENTROPY_COUNT, "entropy_avail" },
> { RANDOM_READ_THRESH, "read_wakeup_threshold" },
> { RANDOM_WRITE_THRESH, "write_wakeup_threshold" },
> { RANDOM_BOOT_ID, "boot_id" },
> { RANDOM_UUID, "uuid" },
> {}
> };
>
> It appears to me, not that I am totally sure because of the lack of
> comments,

Comments? You can read code, can't you?

> that every attempt to add a new direcotry in the tree with
> a number that is not listed in the above mess fails through
> sysctl_binary_lookup.sysctl_binary_lookup, and every attempt to add
> a directory with CTL_UNNUMBERED instead fails if it has children because
> the children cry about having an unnumbered parent. Every attempt to
> add a directory usurping an existing number fails through some string
> mismatch against the trans_.._tables on the dirnames in one of the
> numerous lookup functions (forget which).
>
> (somebody has really spent their holidays on this).
>
> What's a person to do?

If I understand you correcty, the answer is drop '.ctl_name' bits from
new sysctls and make sure common parts of tables match the ones
in mainline.

Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Peter T. Breuer]

"Also sprach Alexey Dobriyan:"
> On 3/1/08, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> > A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
> > from using the /proc/sys/ interface:
> 
> That's somewhat correct.

OK.  Thanks.  That's a relief.  It's always good to know that it's the
universe that's crazy, not me.

> > What's a person to do?
> 
> If I understand you correcty, the answer is drop '.ctl_name' bits from
> new sysctls and make sure common parts of tables match the ones
> in mainline.

You are saying, O wise delphic oracle, that I *can* add stuff in the
/proc/sys tree, provided it's at an approved leaf?  Or that I must use
CTL_UNNUMBERED for flipping efferything, not just most things?  (one
would have thought one was entitled to number things in ones own
subdirectories, failing some comment to the contrary).  I tried
CTL_UNNUMBERED at least on my top level directory, and didn't add any
entries to it, and THAT failed. So on the face of it that
interpretation of your words cannot be correct.

/proc/sys/dev is where I am trying to add a directory, because I am none
of

        { DEV_CDROM,    "cdrom",        trans_cdrom_table },
        { DEV_PARPORT,  "parport",      trans_parport_table },
        { DEV_RAID,     "raid",         trans_raid_table },
        { DEV_MAC_HID,  "mac_hid",      trans_mac_hid_files },
        { DEV_SCSI,     "scsi",         trans_scsi_table },
        { DEV_IPMI,     "ipmi",         trans_ipmi_table },

and those are the legal entries at the moment, and I can't see any
commonality in or among any of those or between them and me. 

That's not a leaf.  However, none of its eventual leaves have anything
to do with my driver.  So here in dev/ would be just fine to plonk a new
device driver subtree, methinks.

And you want me to use CTL_UNNUMBERED for everything in my subtree
from where it branches off?

OK. I'm game. I'll try. I've tried a lot of other things over the past
few days.

And how am I supposed to maintain this driver, now that it's full of
#iffoo < 2.6.24 every two lines?

And while I am here, what's the purpose of this change? What's the
point of checking that only the pre-approved entries to this tree are
made? I don't get it! If you don't want somebody adding something
to /proc/sys just delete their registration call from the kernel
tree, surely! Is this some sort of in-kernel fight? Defenders of
/proc/sys against attackers? Is the problem that one can't persuade
some maintainers to stop their authors from adding to /proc/sys, so
instead it's been made it necessary to ask permission of the /proc/sys
maintainer instead via this change?

Now every author has to make a change in their code AND make a change in
the sysctl code in a totally different part of the kernel when they want
a single change - adding a file or dir to their file hierarchy.

And what's the registration function for, now that the details are
largely there in sysctl.c and sysctl_check.c? It just adds detail
like strategy and proc_handler? And says when to put up and tear down
the subtree in question? Why not move ALL the detail over to
kernel/sysctl.c too!

(if you think I think it's crazy, yes, you are not so crazy).

Peter








 

Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Sat, 01 Mar 2008 02:12:05 +0100, "Peter T. Breuer" said:
> A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
> from using the /proc/sys/ interface:

> 
> What's a person to do? 

Umm.. as a wild guess? Maybe a patch to add entries to the sysctl_check_table
arrays for your sysctl?

They didn't spend their holiday just coming up with this to annoy you - the
checking found a *lot* of entries that were well and truly broken (in the
how-did-it-ever-not-panic sense)...

Yes, it does make it more difficult for out-of-tree modules to create a new
sysctl entry - which is probably just as well, given that there's sysfs and
debugfs and a whole lot of other options as well for userspace-kernel
interaction.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Peter T. Breuer]

"Also sprach Alexey Dobriyan:"
> 
> If I understand you correcty, the answer is drop '.ctl_name' bits from
> new sysctls and make sure common parts of tables match the ones
> in mainline.

YES! Setting .ctl_name to 0 on _every_ _single_ _item_ of my sub-hierarchy
did the trick. Thank you, thank you, thank you.

And how does it know when it gets to the end of a list held as
consecutive entries in an array now? One always used to set .ctl_name
to zero for that marker!

I'd better zero absolutely everything at array end.

Thanks again. I was looking at the documentation for configfs (it
exists!) and muttering "this is way too hard and unsuitable anyway",
and sysfs ("this is just not appropriate"). Sysctl is definitely
the right thing to do for me .. modulo that I would like some finer
control, at my choice, of over when things appear and disappear.

Peter

Re: sysctl in 2.6.24.2 excludes unapproved files from /proc/sys?

[Alexey Dobriyan]

On 3/1/08, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> "Also sprach Alexey Dobriyan:"
> > On 3/1/08, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> > > A change in 2.6.24.x kernel/sysctl.c seems to exclude exo-kernel drivers
> > > from using the /proc/sys/ interface:
> >
> > That's somewhat correct.
>
> OK. Thanks. That's a relief. It's always good to know that it's the
> universe that's crazy, not me.
>
> > > What's a person to do?
> >
> > If I understand you correcty, the answer is drop '.ctl_name' bits from
> > new sysctls and make sure common parts of tables match the ones
> > in mainline.
>
> You are saying, O wise delphic oracle, that I *can* add stuff in the
> /proc/sys tree, provided it's at an approved leaf? Or that I must use
> CTL_UNNUMBERED for flipping efferything, not just most things? (one
> would have thought one was entitled to number things in ones own
> subdirectories, failing some comment to the contrary). I tried
> CTL_UNNUMBERED at least on my top level directory, and didn't add any
> entries to it, and THAT failed. So on the face of it that
> interpretation of your words cannot be correct.
>
> /proc/sys/dev is where I am trying to add a directory, because I am none
> of
>
> { DEV_CDROM, "cdrom", trans_cdrom_table },
> { DEV_PARPORT, "parport", trans_parport_table },
> { DEV_RAID, "raid", trans_raid_table },
> { DEV_MAC_HID, "mac_hid", trans_mac_hid_files },
> { DEV_SCSI, "scsi", trans_scsi_table },
> { DEV_IPMI, "ipmi", trans_ipmi_table },
>
> and those are the legal entries at the moment, and I can't see any
> commonality in or among any of those or between them and me.
>
> That's not a leaf. However, none of its eventual leaves have anything
> to do with my driver. So here in dev/ would be just fine to plonk a new
> device driver subtree, methinks.
>
> And you want me to use CTL_UNNUMBERED for everything in my subtree
> from where it branches off?
>
> OK. I'm game. I'll try. I've tried a lot of other things over the past
> few days.
>
> And how am I supposed to maintain this driver, now that it's full of
> #iffoo < 2.6.24 every two lines?

Out of tree driver -- nobody cares.

> And while I am here, what's the purpose of this change? What's the
> point of checking that only the pre-approved entries to this tree are
> made? I don't get it! If you don't want somebody adding something
> to /proc/sys just delete their registration call from the kernel
> tree, surely! Is this some sort of in-kernel fight? Defenders of
> /proc/sys against attackers? Is the problem that one can't persuade
> some maintainers to stop their authors from adding to /proc/sys, so
> instead it's been made it necessary to ask permission of the /proc/sys
> maintainer instead via this change?

All of this silly and not silly questions are answered by corresponding
commit message. You cited actual patch which started to error out
bad sysctl tables, have you read changelog? It will be very enlightening
for you to do so.

> Now every author has to make a change in their code AND make a change in
> the sysctl code in a totally different part of the kernel when they want
> a single change - adding a file or dir to their file hierarchy.

Correct only for "their code" part.

> And what's the registration function for, now that the details are
> largely there in sysctl.c and sysctl_check.c? It just adds detail
> like strategy and proc_handler? And says when to put up and tear down
> the subtree in question? Why not move ALL the detail over to
> kernel/sysctl.c too!