- 18 Oct, 2007 40 commits
-
-
Daniel Walker authored
Signed-off-by:
Daniel Walker <dwalker@mvista.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Walker authored
Signed-off-by:
-
Daniel Walker authored
Signed-off-by:
-
Daniel Walker authored
Signed-off-by:
-
Daniel Walker authored
Signed-off-by:
-
Daniel Walker authored
Lots of converting spaces to tabs. Signed-off-by:
-
Daniel Walker authored
Signed-off-by:
-
Jesper Juhl authored
drivers/char/mxser.c:386: warning: 'mxser_get_PCI_conf' declared 'static' but never defined when building without CONFIG_PCI. [jesper.juhl@gmail.com: Fix warning: 'CheckIsMoxaMust' defined but not used] Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Alan Cox authored
This is years dead code and it keeps turning up in confusing ways when grepping for stuff. Signed-off-by:
Alan Cox <alan@redhat.com> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Jiri Slaby authored
mxser_new, remove useless comments in mxser_cards It was rest from times, where info about the card was separated (name, ports number and flags). Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Jiri Slaby authored
mxser_new, move to PCI_VDEVICE Signed-off-by:
-
Jiri Slaby authored
mxser_new, upgrade to 1.10 This adds support for new (5 cards) hardware. Signed-off-by:
-
Andrew Morgan authored
The non-filesystem capability meaning of CAP_SETPCAP is that a process, p1, can change the capabilities of another process, p2. This is not the meaning that was intended for this capability at all, and this implementation came about purely because, without filesystem capabilities, there was no way to use capabilities without one process bestowing them on another. Since we now have a filesystem support for capabilities we can fix the implementation of CAP_SETPCAP. The most significant thing about this change is that, with it in effect, no process can set the capabilities of another process. The capabilities of a program are set via the capability convolution rules: pI(post-exec) = pI(pre-exec) pP(post-exec) = (X(aka cap_bset) & fP) | (pI(post-exec) & fI) pE(post-exec) = fE ? pP(post-exec) : 0 at exec() time. As such, the only influence the pre-exec() program can have on the post-exec() program's capabilities are through the pI capability set. The correct implementation for CAP_SETPCAP (and that enabled by this patch) is that it can be used to add extra pI capabilities to the current process - to be picked up by subsequent exec()s when the above convolution rules are applied. Here is how it works: Let's say we have a process, p. It has capability sets, pE, pP and pI. Generally, p, can change the value of its own pI to pI' where (pI' & ~pI) & ~pP = 0. That is, the only new things in pI' that were not present in pI need to be present in pP. The role of CAP_SETPCAP is basically to permit changes to pI beyond the above: if (pE & CAP_SETPCAP) { pI' = anything; /* ie., even (pI' & ~pI) & ~pP != 0 */ } This capability is useful for things like login, which (say, via pam_cap) might want to raise certain inheritable capabilities for use by the children of the logged-in user's shell, but those capabilities are not useful to or needed by the login program itself. One such use might be to limit who can run ping. You set the capabilities of the 'ping' program to be "= cap_net_raw+i", and then only shells that have (pI & CAP_NET_RAW) will be able to run it. Without CAP_SETPCAP implemented as described above, login(pam_cap) would have to also have (pP & CAP_NET_RAW) in order to raise this capability and pass it on through the inheritable set. Signed-off-by:Andrew Morgan <morgan@kernel.org> Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: James Morris <jmorris@namei.org> Cc: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Eric W. Biederman authored
After adding checking to register_sysctl_table and finding a whole new set of bugs. Missed by countless code reviews and testers I have finally lost patience with the binary sysctl interface. The binary sysctl interface has been sort of deprecated for years and finding a user space program that uses the syscall is more difficult then finding a needle in a haystack. Problems continue to crop up, with the in kernel implementation. So since supporting something that no one uses is silly, deprecate sys_sysctl with a sufficient grace period and notice that the handful of user space applications that care can be fixed or replaced. The /proc/sys sysctl interface that people use will continue to be supported indefinitely. This patch moves the tested warning about sysctls from the path where sys_sysctl to a separate path called from both implementations of sys_sysctl, and it adds a proper entry into Documentation/feature-removal-schedule. Allowing us to revisit this in a couple years time and actually kill sys_sysctl. [lethal@linux-sh.org: sysctl: Fix syscall disabled build] Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Eric W. Biederman authored
It turns out that the net/irda code didn't register any of it's binary paths in the global sysctl.h header file so I missed them completely when making an authoritative list of binary sysctl paths in the kernel. So add them to the list of valid binary sysctl paths. Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
-
Eric W. Biederman authored
Well it turns out after I dug into the problems a little more I was returning a few false positives so this patch updates my logic to remove them. - Don't complain about 0 ctl_names in sysctl_check_binary_path It is valid for someone to remove the sysctl binary interface and still keep the same sysctl proc interface. - Count ctl_names and procnames as matching if they both don't exist. - Only warn about missing min&max when the generic functions care. Signed-off-by:
-
Eric W. Biederman authored
After going through the kernels sysctl tables several times it has become clear that code review and testing is just not effective in prevent problematic sysctl tables from being used in the stable kernel. I certainly can't seem to fix the problems as fast as they are introduced. Therefore this patch adds sysctl_check_table which is called when a sysctl table is registered and checks to see if we have a problematic sysctl table. The biggest part of the code is the table of valid binary sysctl entries, but since we have frozen our set of binary sysctls this table should not need to change, and it makes it much easier to detect when someone unintentionally adds a new binary sysctl value. As best as I can determine all of the several hundred errors spewed on boot up now are legitimate. [bunk@kernel.org: kernel/sysctl_check.c must #include <linux/string.h>] Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Eric W. Biederman authored
Grumble. These numbers should have been in sysctl.h from the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier. Signed-off-by:
-
Eric W. Biederman authored
It looks like we inadvertently killed the cad_pid binary sysctl support when cap_pid was changed to be a struct pid. Since no one has complained just remove the binary path. Signed-off-by:
-
Eric W. Biederman authored
No one has bothered to set strategy routine for the the netfilter sysctls that return jiffies to be sysctl_jiffies. So it appears the sys_sysctl path is unused and untested, so this patch removes the binary sysctl numbers. Which fixes the netfilter oops in 2.6.23-rc2-mm2 for me. Signed-off-by:
-
Eric W. Biederman authored
Instead of having a bunch of ifdefs in sysctl.c move all of the pty sysctl logic into drivers/char/pty.c As well as cleaning up the logic this prevents sysctl_check_table from complaining that the root table has a NULL data pointer on something with generic methods. Signed-off-by:
-
Eric W. Biederman authored
The sysctl binary paths don't look as if they even code work, .data is not filled in, and all of the proc_handlers look at extra1 and there is not strategy routine. So just kill the binary paths. In addition this patch removes the setting of extra1 on directories. It doesn't look like the parport code ever examines it, and it's bad sysctl form. [bunk@kernel.org: remove parport_device_num()] Signed-off-by:
-
Eric W. Biederman authored
aio-nr, aio-max-nr, acpi_video_flags are unsigned long values which sysctl does not handle properly with a 64bit kernel and a 32bit user space. Since no one is likely to be using the binary sysctl values and the ascii interface still works, this patch just removes support for the binary sysctl interface from the kernel. Signed-off-by:
-
Eric W. Biederman authored
Currently tcp_available_congestion_control does not even attempt being read from sys_sysctl, and ipfrag_max_dist while it works allows setting of invalid values using sys_sysctl. So just kill the binary sys_sysctl support for these sysctls. If the support is not important enough to test and get right it probably isn't important enough to keep. Signed-off-by:
-
Eric W. Biederman authored
The binary interface for the cdrom sysctls can't possilby work. So remove the binary sysctls and update the test for finding out which sysctl table entry we are dealy with to use the procname and not the ctl_name (which I am removing). Signed-off-by:
-
Eric W. Biederman authored
Signed-off-by:
-
Eric W. Biederman authored
This is debug code so no need to support binary sysctl, and the binary sysctls as they were written were not consistent with what showed up in /proc so remove the binary sysctl support. Signed-off-by:
-
Eric W. Biederman authored
We don't preoperly support the sysctl binary path for flushing the ipv6 routes. So remove support for a binary path. Signed-off-by:
-
Eric W. Biederman authored
- In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. - In neighbour.c reorder the table to put the possibly unused entries at the end so we can remove them by terminating the table early. - In neighbour.c kill the entries with questionable binary sysctl handling behavior. - In neighbour.c if we don't have a strategy routine remove the binary path. So we don't the default sysctl strategy routine on data that is not ready for it. Signed-off-by:
-
Eric W. Biederman authored
These functions are all wrapper functions for the proc interface that are needed for them to work correctly. Signed-off-by:
-
Eric W. Biederman authored
Because of a conflict with FS_INODE_NR none of the binary sysctl numbers use by mqueue, were available to user space. So just remove them. Signed-off-by:
-
Eric W. Biederman authored
There as been no easy way to wrap the default sysctl strategy routine except for returning 0. Which is not always what we want. The few instances I have seen that want different behaviour have written their own version of sysctl_data. While not too hard it is unnecessary code and has the potential for extra bugs. So to make these situations easier and make that part of sysctl more symetric I have factord sysctl_data out of do_sysctl_strategy and exported as a function everyone can use. Further having sysctl_data be an explicit function makes checking for badly formed sysctl tables much easier. Signed-off-by:
-
Eric W. Biederman authored
In sysctl.h the typedef struct ctl_table ctl_table violates coding style isn't needed and is a bit of a nuisance because it makes it harder to recognize ctl_table is a type name. So this patch removes it from the generic sysctl code. Hopefully I will have enough energy to send the rest of my patches will follow and to remove it from the rest of the kernel. Signed-off-by:
-
Jeff Layton authored
If the ATTR_KILL_S*ID bits are set then any mode change is only for clearing the setuid/setgid bits. For CIFS, skip the mode change and let the server handle it. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Cc: Steven French <sfrench@us.ibm.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jeff Layton authored
If the ATTR_KILL_S*ID bits are set then any mode change is only for clearing the setuid/setgid bits. For NFS, skip the mode change and let the server handle it. Signed-off-by:
-
Jeff Layton authored
When an unprivileged process attempts to modify a file that has the setuid or setgid bits set, the VFS will attempt to clear these bits. The VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid mask, and then call notify_change to clear these bits and set the mode accordingly. With a networked filesystem (NFS and CIFS in particular but likely others), the client machine or process may not have credentials that allow for setting the mode. In some situations, this can lead to file corruption, an operation failing outright because the setattr fails, or to races that lead to a mode change being reverted. In this situation, we'd like to just leave the handling of this to the server and ignore these bits. The problem is that by the time the setattr op is called, the VFS has already reinterpreted the ATTR_KILL_* bits into a mode change. The setattr operation has no way to know its intent. The following patch fixes this by making notify_change no longer clear the ATTR_KILL_SUID and ATTR_KILL_SGID bits in the ia_valid before handing it off to the setattr inode op. setattr can then check for the presence of these bits, and if they're set it can assume that the mode change was only for the purposes of clearing these bits. This means that we now have an implicit assumption that notify_change is never called with ATTR_MODE and either ATTR_KILL_S*ID bit set. Nothing currently enforces that, so this patch also adds a BUG() if that occurs. Signed-off-by:
-
Jeff Layton authored
reiserfs_setattr can call notify_change recursively using the same iattr struct. This could cause it to trip the BUG() in notify_change. Fix reiserfs to clear those bits near the beginning of the function. Signed-off-by:
-
Jeff Layton authored
It's theoretically possible for a single SETATTR call to come in that sets the mode and the uid/gid. In that case, don't set the ATTR_KILL_S*ID bits since that would trip the BUG() in notify_change. Just fix up the mode to have the same effect. Signed-off-by:
-
Jeff Layton authored
Make sure ecryptfs doesn't trip the BUG() in notify_change. This also allows the lower filesystem to interpret ATTR_KILL_S*ID in its own way. Signed-off-by:
-
Akinobu Mita authored
- Fix resource leakage in error case within detect_cache_attributes() - Don't register hotcpu notifier when cache_add_dev() returns error - Introduce cache_dev_map cpumask to track whether cache interface for CPU is successfully added by cache_add_dev() or not. cache_add_dev() may fail with out of memory error. In order to avoid cache_remove_dev() with that uninitialized cache interface when CPU_DEAD event is delivered we need to have the cache_dev_map cpumask. (We cannot change cache_add_dev() from CPU_ONLINE event handler to CPU_UP_PREPARE event handler. Because cache_add_dev() needs to do cpuid and store the results with its CPU online.) [nix.or.die@googlemail.com: fix a section mismatch warning] Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Oleg Nesterov <oleg@tv-sign.ru> Cc: Andi Kleen <ak@suse.de> Cc: Jan Beulich <jbeulich@novell.com> Signed-off-by:
Gabriel Craciunescu <nix.or.die@googlemail.com> Signed-off-by:
-
