This is the start of the stable review cycle for the 2.6.11.8 release. There
are 7 patches in this series, all will be posted as a response to this one.
If anyone has any issues with these being applied, please let us know. If
anyone is a maintainer of the proper subsystem, and wants to add a
signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the Bcc: line.
If you wish to be a reviewer, please email [email protected] to add your name to
the list. If you want to be off the reviewer list, also email us.
Responses should be made by Friday, Apr 29 17:00 UTC. Anything received after
that time, might be too late.
thanks,
the -stable release team
-stable review patch. If anyone has any objections, please let us know.
------------------
The kernel currently allows any user permitted to access the tape device file
to send the tape drive commands that may either make the tape drivers internal
state inconsistent or to change the drive parameters so that other users find
the drive to be unusable. This patch changes ioctl handling so that SG_IO,
SCSI_IOCTL_COMMAND, etc. require CAP_ADMIN. This solves the consistency
problems for SCSI tapes. The st driver provides user-accessible commands to
change the drive parameters that users may need to access.
The SCSI command permissions were discussed widely on the linux lists but this
did not result in any useful refinement of the permissions. It may very well
be that the tape drives are the only devices that users are sometimes given
permissions to access and that have security problems with the current command
filtering. This patch solves the problem for tapes and no more elaborate
patches are needed.
Signed-off-by: Kai Makisara <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
diff -Naru a/drivers/scsi/st.c b/drivers/scsi/st.c
--- a/drivers/scsi/st.c 2005-04-27 09:50:24 -07:00
+++ b/drivers/scsi/st.c 2005-04-27 09:50:24 -07:00
@@ -3461,11 +3461,17 @@
case SCSI_IOCTL_GET_BUS_NUMBER:
break;
default:
- i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
+ if (!capable(CAP_SYS_ADMIN))
+ i = -EPERM;
+ else
+ i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
if (i != -ENOTTY)
return i;
break;
}
+ if (!capable(CAP_SYS_ADMIN) &&
+ (cmd_in == SCSI_IOCTL_START_UNIT || cmd_in == SCSI_IOCTL_STOP_UNIT))
+ return -EPERM;
return scsi_ioctl(STp->device, cmd_in, p);
out:
-stable review patch. If anyone has any objections, please let us know.
------------------
Erik reports this fixes an oops on boot for him.
From: Andries Brouwer <[email protected]>
A well-known kernel bug is that it guesses at the partition type and the
partitions on any disk it encounters. This is bad because needless I/O is
done, slowing down the boot, sometimes quite a lot, especially when I/O
errors occur. And it is bad because sometimes we guess wrong.
In other words, we need the user space command `partition', where
"partition -t dos /dev/sda" reads a DOS-type partition table. (And
"partition /dev/sda" tries all known heuristics to decide what type of
partitioning might be present.) The two variants are: (i) partition tells
the kernel to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one about the
partitions found this way.
Since this is a fundamental change, a long transition period is needed, and
that period could start with a kernel boot parameter telling the kernel not
to do partition table parsing on a particular disk, or a particular type of
disks, or all disks.
This could have been the intro to a patch doing that, but is not. (It is
just an RFC.)
The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing. It causes the
kernel to ignore partitions of type 0. A band-aid.
I think nobody uses such partitions seriously, but nevertheless this should
probably live in -mm for a while to see if anybody complains.
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
===== fs/partitions/msdos.c 1.26 vs 1.27 =====
--- 1.26/fs/partitions/msdos.c 2004-11-09 12:43:17 -08:00
+++ 1.27/fs/partitions/msdos.c 2005-03-07 20:41:42 -08:00
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions
*/
for (i=0; i<4; i++, p++) {
u32 offs, size, next;
+
+ if (SYS_IND(p) == 0)
+ continue;
if (!NR_SECTS(p) || is_extended_partition(p))
continue;
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-stable review patch. If anyone has any objections, please let us know.
------------------
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- linux-2.6.12-rc1-bk5/drivers/i2c/chips/it87.c.orig 2005-04-02 18:09:59.000000000 +0200
+++ linux-2.6.12-rc1-bk5/drivers/i2c/chips/it87.c 2005-04-02 21:12:46.000000000 +0200
@@ -668,7 +668,7 @@
struct it87_data *data = it87_update_device(dev);
return sprintf(buf,"%d\n", ALARMS_FROM_REG(data->alarms));
}
-static DEVICE_ATTR(alarms, S_IRUGO | S_IWUSR, show_alarms, NULL);
+static DEVICE_ATTR(alarms, S_IRUGO, show_alarms, NULL);
static ssize_t
show_vrm_reg(struct device *dev, char *buf)
--- linux-2.6.12-rc1-bk5/drivers/i2c/chips/via686a.c.orig 2005-04-02 18:22:48.000000000 +0200
+++ linux-2.6.12-rc1-bk5/drivers/i2c/chips/via686a.c 2005-04-02 21:12:55.000000000 +0200
@@ -574,7 +574,7 @@
struct via686a_data *data = via686a_update_device(dev);
return sprintf(buf,"%d\n", ALARMS_FROM_REG(data->alarms));
}
-static DEVICE_ATTR(alarms, S_IRUGO | S_IWUSR, show_alarms, NULL);
+static DEVICE_ATTR(alarms, S_IRUGO, show_alarms, NULL);
/* The driver. I choose to use type i2c_driver, as at is identical to both
smbus_driver and isa_driver, and clients could be of either kind */
--
Jean Delvare
-stable review patch. If anyone has any objections, please let us know.
------------------
Jani Jaakkola <[email protected]> wrote:
>
> SMP race handling is broken in key_user_lookup() in security/keys/key.c
This was fixed post-2.6.11. Can you confirm that 2.6.12-rc2 works OK?
This is the patch we used. It should go into -stable if it's not already
there.
From: Alexander Nyberg <[email protected]>
I looked at some of the oops reports against keyrings, I think the problem
is that the search isn't restarted after dropping the key_user_lock, *p
will still be NULL when we get back to try_again and look through the tree.
It looks like the intention was that the search start over from scratch.
Signed-off-by: Alexander Nyberg <[email protected]>
Cc: David Howells <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
25-akpm/security/keys/key.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN security/keys/key.c~race-against-parent-deletion-in-key_user_lookup security/keys/key.c
--- 25/security/keys/key.c~race-against-parent-deletion-in-key_user_lookup 2005-03-10 00:38:38.000000000 -0800
+++ 25-akpm/security/keys/key.c 2005-03-10 00:38:38.000000000 -0800
@@ -57,9 +57,10 @@ struct key_user *key_user_lookup(uid_t u
{
struct key_user *candidate = NULL, *user;
struct rb_node *parent = NULL;
- struct rb_node **p = &key_user_tree.rb_node;
+ struct rb_node **p;
try_again:
+ p = &key_user_tree.rb_node;
spin_lock(&key_user_lock);
/* search the tree for a user record with a matching UID */
_
-stable review patch. If anyone has any objections, please let us know.
------------------
Here's a patch that fixes
http://bugme.osdl.org/show_bug.cgi?id=4395.
In case there's a 2.6.11.7 before 2.6.12 is released it would
be nice to include this patch there, too.
Johannes
---
Patch by Manu Abraham and Gerd Knorr:
Remove redundant bttv_reset_audio() which caused the computer to
freeze with some bt8xx based DVB cards when loading the bttv driver.
Signed-off-by: Johannes Stezenbach <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- linux-2.6.12-rc2.orig/drivers/media/video/bttv-cards.c 2005-04-05 02:35:41.000000000 +0200
+++ linux-2.6.12-rc2/drivers/media/video/bttv-cards.c 2005-04-05 02:37:31.000000000 +0200
@@ -2785,8 +2785,6 @@ void __devinit bttv_init_card2(struct bt
}
btv->pll.pll_current = -1;
- bttv_reset_audio(btv);
-
/* tuner configuration (from card list / autodetect / insmod option) */
if (UNSET != bttv_tvcards[btv->c.type].tuner_type)
if(UNSET == btv->tuner_type)
-stable review patch. If anyone has any objections, please let us know.
------------------
I'm resending this for inclusion in the -stable tree. I've deleted whitespace
cleanups, and hope this can be merged. I've been asked to split the former
patch, I don't know if I must split again this one, even because I don't want
to split this correct patch into multiple non-correct ones by mistake.
Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are
duplicated, and that GCC does not accept this (unlike gcc 3). Plus various
other bugs in the syscall table definitions, resulting in probable wrong
syscall entries:
*) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a
valid syscall (thus a duplicated one).
*) __NR_vserver must be only once with sys_ni_syscall, and not multiple
times with different values!
*) syscalls duplicated in SUBARCHs and in common files (thus assigning twice
to the same array entry and causing the GCC 2.95.4 failure mentioned above):
sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64,
sys_fstatfs64, which exist only on i386.
*) syscalls duplicated in each SUBARCH, to put in common files:
sys_remap_file_pages, sys_utimes, sys_fadvise64
*) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range
does not arrive to that point.
*) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load.
Use the correct name in either case.
Note: as you can see, part of the syscall table definition in UML is
arch-independent (with everywhere defined syscalls), and part is
arch-dependant. This has created confusion (some syscalls are listed in both
places, some in the wrong one, some are wrong on one arch or another).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h | 12 +++++-----
clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h | 5 ----
clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c | 11 +++------
3 files changed, 10 insertions(+), 18 deletions(-)
diff -puN arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-i386/syscalls.h
--- clean-linux-2.6.11/arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable 2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h 2005-04-05 16:56:57.000000000 +0200
@@ -23,6 +23,9 @@ extern long sys_mmap2(unsigned long addr
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff);
+/* On i386 they choose a meaningless naming.*/
+#define __NR_kexec_load __NR_sys_kexec_load
+
#define ARCH_SYSCALLS \
[ __NR_waitpid ] = (syscall_handler_t *) sys_waitpid, \
[ __NR_break ] = (syscall_handler_t *) sys_ni_syscall, \
@@ -101,15 +104,12 @@ extern long sys_mmap2(unsigned long addr
[ 223 ] = (syscall_handler_t *) sys_ni_syscall, \
[ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
[ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
- [ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \
[ 251 ] = (syscall_handler_t *) sys_ni_syscall, \
- [ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \
- [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \
- [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall,
-
+ [ 285 ] = (syscall_handler_t *) sys_ni_syscall,
+
/* 222 doesn't yet have a name in include/asm-i386/unistd.h */
-#define LAST_ARCH_SYSCALL __NR_vserver
+#define LAST_ARCH_SYSCALL 285
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
diff -puN arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-x86_64/syscalls.h
--- clean-linux-2.6.11/arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable 2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h 2005-04-05 16:56:57.000000000 +0200
@@ -71,12 +71,7 @@ extern syscall_handler_t sys_arch_prctl;
[ __NR_iopl ] = (syscall_handler_t *) sys_ni_syscall, \
[ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
[ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
- [ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \
[ __NR_semtimedop ] = (syscall_handler_t *) sys_semtimedop, \
- [ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \
- [ 223 ] = (syscall_handler_t *) sys_ni_syscall, \
- [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \
- [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall, \
[ 251 ] = (syscall_handler_t *) sys_ni_syscall,
#define LAST_ARCH_SYSCALL 251
diff -puN arch/um/kernel/sys_call_table.c~uml-quick-fix-syscall-table-for-stable arch/um/kernel/sys_call_table.c
--- clean-linux-2.6.11/arch/um/kernel/sys_call_table.c~uml-quick-fix-syscall-table-for-stable 2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c 2005-04-05 16:56:57.000000000 +0200
@@ -48,7 +48,6 @@ extern syscall_handler_t sys_vfork;
extern syscall_handler_t old_select;
extern syscall_handler_t sys_modify_ldt;
extern syscall_handler_t sys_rt_sigsuspend;
-extern syscall_handler_t sys_vserver;
extern syscall_handler_t sys_mbind;
extern syscall_handler_t sys_get_mempolicy;
extern syscall_handler_t sys_set_mempolicy;
@@ -242,6 +241,7 @@ syscall_handler_t *sys_call_table[] = {
[ __NR_epoll_create ] = (syscall_handler_t *) sys_epoll_create,
[ __NR_epoll_ctl ] = (syscall_handler_t *) sys_epoll_ctl,
[ __NR_epoll_wait ] = (syscall_handler_t *) sys_epoll_wait,
+ [ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages,
[ __NR_set_tid_address ] = (syscall_handler_t *) sys_set_tid_address,
[ __NR_timer_create ] = (syscall_handler_t *) sys_timer_create,
[ __NR_timer_settime ] = (syscall_handler_t *) sys_timer_settime,
@@ -252,12 +252,10 @@ syscall_handler_t *sys_call_table[] = {
[ __NR_clock_gettime ] = (syscall_handler_t *) sys_clock_gettime,
[ __NR_clock_getres ] = (syscall_handler_t *) sys_clock_getres,
[ __NR_clock_nanosleep ] = (syscall_handler_t *) sys_clock_nanosleep,
- [ __NR_statfs64 ] = (syscall_handler_t *) sys_statfs64,
- [ __NR_fstatfs64 ] = (syscall_handler_t *) sys_fstatfs64,
[ __NR_tgkill ] = (syscall_handler_t *) sys_tgkill,
[ __NR_utimes ] = (syscall_handler_t *) sys_utimes,
- [ __NR_fadvise64_64 ] = (syscall_handler_t *) sys_fadvise64_64,
- [ __NR_vserver ] = (syscall_handler_t *) sys_vserver,
+ [ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64,
+ [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall,
[ __NR_mbind ] = (syscall_handler_t *) sys_mbind,
[ __NR_get_mempolicy ] = (syscall_handler_t *) sys_get_mempolicy,
[ __NR_set_mempolicy ] = (syscall_handler_t *) sys_set_mempolicy,
@@ -267,9 +265,8 @@ syscall_handler_t *sys_call_table[] = {
[ __NR_mq_timedreceive ] = (syscall_handler_t *) sys_mq_timedreceive,
[ __NR_mq_notify ] = (syscall_handler_t *) sys_mq_notify,
[ __NR_mq_getsetattr ] = (syscall_handler_t *) sys_mq_getsetattr,
- [ __NR_sys_kexec_load ] = (syscall_handler_t *) sys_ni_syscall,
+ [ __NR_kexec_load ] = (syscall_handler_t *) sys_ni_syscall,
[ __NR_waitid ] = (syscall_handler_t *) sys_waitid,
- [ 285 ] = (syscall_handler_t *) sys_ni_syscall,
[ __NR_add_key ] = (syscall_handler_t *) sys_add_key,
[ __NR_request_key ] = (syscall_handler_t *) sys_request_key,
[ __NR_keyctl ] = (syscall_handler_t *) sys_keyctl,
_
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
-stable review patch. If anyone has any objections, please let us know.
------------------
This trick is useless, because sys_ni.c will handle this problem by itself,
like it does even on UML for other syscalls.
Also, it does not provide the NFSD syscall when NFSD is compiled as a module,
which is a big problem.
This should be merged currently in both 2.6.11-stable and the current tree.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c | 8 +-------
1 files changed, 1 insertion(+), 7 deletions(-)
diff -puN arch/um/kernel/sys_call_table.c~uml-nfsd-syscall arch/um/kernel/sys_call_table.c
--- clean-linux-2.6.11/arch/um/kernel/sys_call_table.c~uml-nfsd-syscall 2005-04-10 13:50:29.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c 2005-04-10 13:51:19.000000000 +0200
@@ -14,12 +14,6 @@
#include "sysdep/syscalls.h"
#include "kern_util.h"
-#ifdef CONFIG_NFSD
-#define NFSSERVCTL sys_nfsservctl
-#else
-#define NFSSERVCTL sys_ni_syscall
-#endif
-
#define LAST_GENERIC_SYSCALL __NR_keyctl
#if LAST_GENERIC_SYSCALL > LAST_ARCH_SYSCALL
@@ -190,7 +184,7 @@ syscall_handler_t *sys_call_table[] = {
[ __NR_getresuid ] = (syscall_handler_t *) sys_getresuid16,
[ __NR_query_module ] = (syscall_handler_t *) sys_ni_syscall,
[ __NR_poll ] = (syscall_handler_t *) sys_poll,
- [ __NR_nfsservctl ] = (syscall_handler_t *) NFSSERVCTL,
+ [ __NR_nfsservctl ] = (syscall_handler_t *) sys_nfsservctl,
[ __NR_setresgid ] = (syscall_handler_t *) sys_setresgid16,
[ __NR_getresgid ] = (syscall_handler_t *) sys_getresgid16,
[ __NR_prctl ] = (syscall_handler_t *) sys_prctl,
_
On Mer, 2005-04-27 at 18:15, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
Don't see why this one is a critical bug.
On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
This patch is just wrong on so many different levels its hard to know
where to begin.
1. The auth for arbitary commands is CAP_SYS_RAWIO
2. "The SCSI command permissions were discussed widely on the linux
lists but this did not result in any useful refinement of the
permissions." - this is false. The process was refined, a table setup
was added and debugged. Someone even wrote an fs for managing it that is
not yet merged. Perhaps the patch author would care to re-read the
archives and submit a new patch if one is even needed
3. Pleas explain *what* the specific consistency problems are
And then please fix the same mess in 12rc.
Alan
* Alan Cox ([email protected]) wrote:
> On Mer, 2005-04-27 at 18:15, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> Don't see why this one is a critical bug.
I guess without it, modular nfsd has no syscall interface (for UML, or
course).
thanks,
-chris
On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > Don't see why this one is a critical bug.
>
> I guess without it, modular nfsd has no syscall interface (for UML, or
> course).
And the trivial zero risk fix is to compile it in. Its hardly pressing
* Greg KH ([email protected]) wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release. There
> are 7 patches in this series, all will be posted as a response to this one.
There are actually 10. We missed 3 patches from DaveM (100% my fault,
somehow I messed up pushing them into the queue 10 days ago). Those three
will follow-up shortly as 8/7, 9/7, and 10/7. Sorry for the mix up.
thanks,
-chris
On Wed, Apr 27, 2005 at 05:38:49PM +0100, Alan Cox wrote:
> On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> This patch is just wrong on so many different levels its hard to know
> where to begin.
But that is what is now in mainline, right? If so, all of these
questions still pertain to the current tree...
> 1. The auth for arbitary commands is CAP_SYS_RAWIO
> 2. "The SCSI command permissions were discussed widely on the linux
> lists but this did not result in any useful refinement of the
> permissions." - this is false. The process was refined, a table setup
> was added and debugged. Someone even wrote an fs for managing it that is
> not yet merged. Perhaps the patch author would care to re-read the
> archives and submit a new patch if one is even needed
> 3. Pleas explain *what* the specific consistency problems are
>
> And then please fix the same mess in 12rc.
thanks,
greg k-h
-stable review patch. If anyone has any objections, please let us know.
------------------
Because this routine was not filling in the siginfo
values for si_band and si_fd, this broke applications
trying to actually get at this data.
This makes the sparc64 code in line with PowerPC64's
implementation, which already gets it right.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
===== arch/sparc64/kernel/signal32.c 1.52 vs edited =====
--- 1.52/arch/sparc64/kernel/signal32.c 2005-03-13 15:29:47 -08:00
+++ edited/arch/sparc64/kernel/signal32.c 2005-04-17 14:37:13 -07:00
@@ -192,9 +192,12 @@
err |= __put_user(from->si_uid, &to->si_uid);
break;
case __SI_FAULT >> 16:
- case __SI_POLL >> 16:
err |= __put_user(from->si_trapno, &to->si_trapno);
err |= __put_user((unsigned long)from->si_addr, &to->si_addr);
+ break;
+ case __SI_POLL >> 16:
+ err |= __put_user(from->si_band, &to->si_band);
+ err |= __put_user(from->si_fd, &to->si_fd);
break;
case __SI_RT >> 16: /* This is not generated by the kernel as of now. */
case __SI_MESGQ >> 16:
-stable review patch. If anyone has any objections, please let us know.
------------------
A couple message queue system call entries for compat tasks
were not using the necessary compat_sys_*() functions, causing
some glibc test cases to fail.
From: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
===== arch/sparc64/kernel/systbls.S 1.69 vs edited =====
--- 1.69/arch/sparc64/kernel/systbls.S 2005-01-14 11:56:05 -08:00
+++ edited/arch/sparc64/kernel/systbls.S 2005-04-11 15:09:49 -07:00
@@ -75,7 +75,7 @@
/*260*/ .word compat_sys_sched_getaffinity, compat_sys_sched_setaffinity, sys32_timer_settime, compat_sys_timer_gettime, sys_timer_getoverrun
.word sys_timer_delete, sys32_timer_create, sys_ni_syscall, compat_sys_io_setup, sys_io_destroy
/*270*/ .word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink
- .word sys_mq_timedsend, sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid
+ .word compat_sys_mq_timedsend, compat_sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid
/*280*/ .word sys_ni_syscall, sys_add_key, sys_request_key, sys_keyctl
#endif /* CONFIG_COMPAT */
-stable review patch. If anyone has any objections, please let us know.
------------------
SunOS aparently had this weird PTRACE_CONT semantic which
we copied. If the addr argument is something other than
1, it sets the process program counter to whatever that
value is.
This is different from every other Linux architecture, which
don't do anything with the addr and data args.
This difference in particular breaks the Linux native GDB support
for fork and vfork tracing on sparc and sparc64.
There is no interest in running SunOS binaries using this weird
PTRACE_CONT behavior, so just delete it so we behave like other
platforms do.
From: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
===== arch/sparc/kernel/ptrace.c 1.22 vs edited =====
--- 1.22/arch/sparc/kernel/ptrace.c 2005-03-13 15:29:55 -08:00
+++ edited/arch/sparc/kernel/ptrace.c 2005-04-13 22:37:33 -07:00
@@ -531,18 +531,6 @@
pt_error_return(regs, EIO);
goto out_tsk;
}
- if (addr != 1) {
- if (addr & 3) {
- pt_error_return(regs, EINVAL);
- goto out_tsk;
- }
-#ifdef DEBUG_PTRACE
- printk ("Original: %08lx %08lx\n", child->thread.kregs->pc, child->thread.kregs->npc);
- printk ("Continuing with %08lx %08lx\n", addr, addr+4);
-#endif
- child->thread.kregs->pc = addr;
- child->thread.kregs->npc = addr + 4;
- }
if (request == PTRACE_SYSCALL)
set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
===== arch/sparc64/kernel/ptrace.c 1.24 vs edited =====
--- 1.24/arch/sparc64/kernel/ptrace.c 2005-02-10 19:06:44 -08:00
+++ edited/arch/sparc64/kernel/ptrace.c 2005-04-16 20:52:21 -07:00
@@ -514,25 +563,6 @@
pt_error_return(regs, EIO);
goto out_tsk;
}
- if (addr != 1) {
- unsigned long pc_mask = ~0UL;
-
- if ((child->thread_info->flags & _TIF_32BIT) != 0)
- pc_mask = 0xffffffff;
-
- if (addr & 3) {
- pt_error_return(regs, EINVAL);
- goto out_tsk;
- }
-#ifdef DEBUG_PTRACE
- printk ("Original: %016lx %016lx\n",
- child->thread_info->kregs->tpc,
- child->thread_info->kregs->tnpc);
- printk ("Continuing with %016lx %016lx\n", addr, addr+4);
-#endif
- child->thread_info->kregs->tpc = (addr & pc_mask);
- child->thread_info->kregs->tnpc = ((addr + 4) & pc_mask);
- }
if (request == PTRACE_SYSCALL) {
set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
* Alan Cox ([email protected]) wrote:
> On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > > Don't see why this one is a critical bug.
> >
> > I guess without it, modular nfsd has no syscall interface (for UML, or
> > course).
>
> And the trivial zero risk fix is to compile it in. Its hardly pressing
OK, let's drop it.
thanks,
-chris
On Mer, 2005-04-27 at 19:26, Greg KH wrote:
> > This patch is just wrong on so many different levels its hard to know
> > where to begin.
>
> But that is what is now in mainline, right? If so, all of these
> questions still pertain to the current tree...
Correct, the 12rc code is also completely wrong. Good job we caught it
since its apparently not been reviewed properly until now.
On Mer, 2005-04-27 at 19:38, Chris Wright wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
>
> SunOS aparently had this weird PTRACE_CONT semantic which
> we copied. If the addr argument is something other than
> 1, it sets the process program counter to whatever that
> value is.
7-9 look sane don't see why 10 is a critical issue but then its in arch
specific obscure code and obvious.
Alan
On 4/27/05, Greg KH <[email protected]> wrote:
>
> -stable review patch. If anyone has any objections, please let us know.
>
While the patch is correct I'd have something like this as well:
--- linux-2.6.11.orig/fs/sysfs/file.c
+++ linux-2.6.11/fs/sysfs/file.c
@@ -36,7 +36,7 @@ subsys_attr_store(struct kobject * kobj,
{
struct subsystem * s = to_subsys(kobj);
struct subsys_attribute * sattr = to_sattr(attr);
- ssize_t ret = 0;
+ ssize_t ret = -ENOSYS;
if (sattr->store)
ret = sattr->store(s,page,count);
So writes without store handler would return "not implemented".
(It is whitespace-mangled and therefore not a real patch - so no
signed-off-by...)
--
Dmitry
On 4/27/05, Dmitry Torokhov <[email protected]> wrote:
> On 4/27/05, Greg KH <[email protected]> wrote:
> >
> > -stable review patch. If anyone has any objections, please let us know.
> >
>
> While the patch is correct I'd have something like this as well:
>
> --- linux-2.6.11.orig/fs/sysfs/file.c
> +++ linux-2.6.11/fs/sysfs/file.c
> @@ -36,7 +36,7 @@ subsys_attr_store(struct kobject * kobj,
> {
> struct subsystem * s = to_subsys(kobj);
> struct subsys_attribute * sattr = to_sattr(attr);
> - ssize_t ret = 0;
> + ssize_t ret = -ENOSYS;
>
> if (sattr->store)
> ret = sattr->store(s,page,count);
>
> So writes without store handler would return "not implemented".
>
Obviously driver_sysfs_ops, bus_sysfs_ops, etc need the same treatment...
--
Dmitry
On Wed, Apr 27, 2005 at 10:16:27AM -0700, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> Erik reports this fixes an oops on boot for him.
No objections. But..
The purpose of this patch was not to fix an oops, but to avoid
partition table parsing in a situation where almost surely
no partition table is present.
If this fixes an oops, then I want to know precisely what oops.
No doubt that same oops could occur in other circumstances where
this patch does not happen to help.
Andries
Am Mittwoch, den 27.04.2005, 22:34 +0200 schrieb Andries Brouwer:
> On Wed, Apr 27, 2005 at 10:16:27AM -0700, Greg KH wrote:
>
> > -stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> >
> > Erik reports this fixes an oops on boot for him.
>
> No objections. But..
>
> The purpose of this patch was not to fix an oops, but to avoid
> partition table parsing in a situation where almost surely
> no partition table is present.
>
> If this fixes an oops, then I want to know precisely what oops.
> No doubt that same oops could occur in other circumstances where
> this patch does not happen to help.
Hi, this happend on my laptop (ibm thinkpad t41p, intel cpu, no special
kind of partition layout). Because this happend during partition table
parsing (during bootup), I was not able to copy it.
But this should only affect the first 512 bytes of my harddisk, or? If
so, I can copy this data and send it to you.
On Wed, Apr 27, 2005 at 10:49:28PM +0200, Erik Tews wrote:
> But this should only affect the first 512 bytes of my harddisk, or? If
> so, I can copy this data and send it to you.
Yes, please do.
(There are various ways in which more data could be involved,
but the first sector is a good start.)
Andries
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release. There
> are 7 patches in this series, all will be posted as a response to this one.
> If anyone has any issues with these being applied, please let us know. If
> anyone is a maintainer of the proper subsystem, and wants to add a
> signed-off-by: line to the patch, please respond with it.
>
> These patches are sent out with a number of different people on the Bcc: line.
> If you wish to be a reviewer, please email [email protected] to add your name to
> the list. If you want to be off the reviewer list, also email us.
>
> Responses should be made by Friday, Apr 29 17:00 UTC. Anything received after
> that time, might be too late.
>
> thanks,
>
> the -stable release team
>
Wanna take some buffer fixes?
--
SUSE Labs, Novell Inc.
* Nick Piggin ([email protected]) wrote:
> Wanna take some buffer fixes?
Do they meet the -stable criteria? If so, please send 'em over.
thanks,
-chris
Chris Wright wrote:
> * Nick Piggin ([email protected]) wrote:
>
>>Wanna take some buffer fixes?
>
>
> Do they meet the -stable criteria? If so, please send 'em over.
>
Where do I find the -stable criteria?
They are a little bit tested, reviewed by Andrew Morton.
To me they seem pretty important. But maybe they should wait until
they have at least seen an -mm release.
The first fix I think closes potential access to stale kernel memory
if you care about that sort of thing.
--
SUSE Labs, Novell Inc.
On Wed, 27 Apr 2005, Chris Wright wrote:
> * Nick Piggin ([email protected]) wrote:
> > Wanna take some buffer fixes?
>
> Do they meet the -stable criteria? If so, please send 'em over.
Shouldn't they see testing time in a tree first?
Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
>
>
>>* Nick Piggin ([email protected]) wrote:
>>
>>>Wanna take some buffer fixes?
>>
>>Do they meet the -stable criteria? If so, please send 'em over.
>
>
> Shouldn't they see testing time in a tree first?
>
Yes they should.
--
SUSE Labs, Novell Inc.
On Wed, Apr 27, 2005 at 07:51:35PM -0600, Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
>
> > * Nick Piggin ([email protected]) wrote:
> > > Wanna take some buffer fixes?
> >
> > Do they meet the -stable criteria? If so, please send 'em over.
>
> Shouldn't they see testing time in a tree first?
I would say that if they meet the stable criteria, testing time in another
tree is not really necessary. Stable should be simple bug fixes, easy to
test. In this case, the fact that Nick seems to think they might need a
run in mm first would tell me that at least some of them probably should
not be in the stable tree at this point.
Justin
On Wed, 27 Apr 2005, Alan Cox wrote:
> On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> This patch is just wrong on so many different levels its hard to know
> where to begin.
>
> 1. The auth for arbitary commands is CAP_SYS_RAWIO
Valid complaint.
> 2. "The SCSI command permissions were discussed widely on the linux
> lists but this did not result in any useful refinement of the
> permissions." - this is false. The process was refined, a table setup
> was added and debugged.
Any user having write access to the device is still allowed to send MODE
SELECT (and some other commands useful for CD/DVD writers but being
potentially dangerous to other). The assumption that _any_ command needed
for burning CDs/DVDs is safe for all device types is ridiculous. This is
why I don't consider the refinements useful.
Controlling high-level access and pass-through with the same permissions
is not a very good model.
> Someone even wrote an fs for managing it that is
> not yet merged.
Yes. So we should wait for a miracle happen and it get merged? My patch
is meant to fix the problems at low level until a more general fix is
merged (if that ever happens).
> Perhaps the patch author would care to re-read the
> archives and submit a new patch if one is even needed
> 3. Pleas explain *what* the specific consistency problems are
OK. Once again....
Using MODE SELECT you can change the drive behaviour so that it may become
practically useless for other users (and even break very quickly). A
simple method is to disable drive buffering. The inconsistency here is
that to the users the drive status is not what the system managers meant
it to be.
Another inconsistency comes from using commands moving the tape so that
the tape driver does not know it. The tape driver provides users some
status information about the tape head location (file and block number,
BOT, EOF, etc.). This information is not valid if tape is moved using
pass-through. The basic problem is that the driver for this kind of a
sequential access device has to maintain some state information and it
gets distorted if pass-through is used. One solution would, of course, be
to interpret the commands and statuses going to/coming from pass-through
but this is a quite heavy solution.
OK. If the Linux solution to these kind of security problems in the not so
central areas of kernel is to wait and see if the problem disappears
without any action, I have to accept that. But I have tried...
--
Kai
On Wednesday 27 April 2005 12:16, Greg KH wrote:
> As a side note, wouldn't it make sense to check, when creating sysfs
> files, that readable files have a non-NULL show method, and writable
> files have a non-NULL store method? I know drivers are not supposed to
> do stupid things, but there is already a BUG_ON for several conditions
> in sysfs_create_file, so maybe we could add two more?
Checking at creation time is not enough. Even with such check one could
change permissions on a sysfs file and set write bit.
--
Dmitry
Hi Greg, hi Takashi,
I would suggest these two patches for inclusion into the stable tree. They
both fix a keyboard lockup when unplugging USB audio hardware.
With the first one applied I can plug / unplug my webcam without losing my
keyboard. I couldn't test the second one, but both patches are in ALSA CVS.
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usbaudio.c?r1=1.119&r2=1.120
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usx2y/usbusx2y.c?r1=1.9&r2=1.10
Cheers,
Gregor
On Thu, Apr 28, 2005 at 08:49:53AM +0200, Gregor Jasny wrote:
> Hi Greg, hi Takashi,
>
> I would suggest these two patches for inclusion into the stable tree. They
> both fix a keyboard lockup when unplugging USB audio hardware.
>
> With the first one applied I can plug / unplug my webcam without losing my
> keyboard. I couldn't test the second one, but both patches are in ALSA CVS.
>
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usbaudio.c?r1=1.119&r2=1.120
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usx2y/usbusx2y.c?r1=1.9&r2=1.10
Are they in the mainline kernel tree already?
Care to send them individually to the stable@ address, along with full
changelog information and signed-off-by lines?
thanks,
greg k-h
On Iau, 2005-04-28 at 06:43, Kai Makisara wrote:
> Any user having write access to the device is still allowed to send MODE
> SELECT (and some other commands useful for CD/DVD writers but being
> potentially dangerous to other). The assumption that _any_ command needed
> for burning CDs/DVDs is safe for all device types is ridiculous. This is
> why I don't consider the refinements useful.
Ok thats the bit I needed to know
> Using MODE SELECT you can change the drive behaviour so that it may become
> practically useless for other users (and even break very quickly). A
> simple method is to disable drive buffering. The inconsistency here is
> that to the users the drive status is not what the system managers meant
> it to be.
Equally users will want to change the drive status and in some
situations will be changing the drive status habitually when using the
tape devices. That seems to have tape level ioctls anyway.
> Another inconsistency comes from using commands moving the tape so that
> the tape driver does not know it. The tape driver provides users some
> status information about the tape head location (file and block number,
> BOT, EOF, etc.). This information is not valid if tape is moved using
> pass-through. The basic problem is that the driver for this kind of a
> sequential access device has to maintain some state information and it
> gets distorted if pass-through is used. One solution would, of course, be
> to interpret the commands and statuses going to/coming from pass-through
> but this is a quite heavy solution.
That isn't a problem. The other drivers and O_DIRECT all take the same
basic approach that users doing raw I/O commands can shoot themselves in
the feet. Anything else stops people doing clever things they need to.
What it must not allow (as you explained in your example with mode
select) is let people shoot each other in the feet.
On the info you give making it CAP_SYS_RAWIO for now does appear to make
sense. A tape safe command or filter list might be better eventually
(and/or making the driver put the state back right on open - which may
also be neccessary when drives get powered off independantly of the
host...)
Alan
Hi!
> -stable review patch. If anyone has any objections, please let us know.
Well, patch author says it should go to mm...:
> I think nobody uses such partitions seriously, but nevertheless this should
> probably live in -mm for a while to see if anybody complains.
...seems like enough not to let it into .8...
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Thu, Apr 28, 2005 at 11:43:17AM +1000, Nick Piggin wrote:
> Chris Wright wrote:
> >* Nick Piggin ([email protected]) wrote:
> >
> >>Wanna take some buffer fixes?
> >
> >
> >Do they meet the -stable criteria? If so, please send 'em over.
> >
>
> Where do I find the -stable criteria?
Here they are again, I will send a patch that adds them to the kernel
tree.
thanks,
greg k-h
------
Everything you ever wanted to know about Linux 2.6 -stable releases.
Rules on what kind of patches are accepted, and what ones are not, into
the "-stable" tree:
- It must be obviously correct and tested.
- It can not bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing.)
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short,
something critical.
- No "theoretical race condition" issues, unless an explanation of how
the race can be exploited.
- It can not contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc.)
- It must be accepted by the relevant subsystem maintainer.
- It must be accepted to mainline, or the accepted mainline patch be
deemed too complex or risky to backport and thus a simple obvious
alternative fix applied to stable ONLY.
- It must follow Documentation/SubmittingPatches rules.
Procedure for submitting patches to the -stable tree:
- Send the patch, after verifying that it follows the above rules, to
[email protected].
- The sender will receive an ack when the patch has been accepted into
the queue, or a nak if the patch is rejected. This response might
take a few days, according to the developer's schedules.
- If accepted, the patch will be added to the -stable queue, for review
by other developers.
- Security patches should not be sent to this alias, but instead to the
documented [email protected].
Review cycle:
- When the -stable maintainers decide for a review cycle, the patches
will be sent to the review committee, and the maintainer of the
affected area of the patch (unless the submitter is the maintainer of
the area) and CC: to the linux-kernel mailing list.
- The review committee has 48 hours in which to ack or nak the patch.
- If the patch is rejected by a member of the committee, or linux-kernel
members object to the patch, bringing up issues that the maintainers
and members did not realize, the patch will be dropped from the
queue.
- At the end of the review cycle, the acked patches will be added to
the latest -stable release, and a new -stable release will happen.
- Security patches will be accepted into the -stable tree directly from
the security kernel team, and not go through the normal review cycle.
Contact the kernel security team for more details on this procedure.
Review committe:
- This will be made up of a number of kernel developers who have
volunteered for this task, and a few that haven't.
On Thu, Apr 28, 2005 at 02:21:52PM +0100, Alan Cox wrote:
> On Iau, 2005-04-28 at 06:43, Kai Makisara wrote:
> > Any user having write access to the device is still allowed to send MODE
> > SELECT (and some other commands useful for CD/DVD writers but being
> > potentially dangerous to other). The assumption that _any_ command needed
> > for burning CDs/DVDs is safe for all device types is ridiculous. This is
> > why I don't consider the refinements useful.
>
> Ok thats the bit I needed to know
So, do you still object to this patch being accepted?
thanks,
greg k-h
On Wed, Apr 27, 2005 at 11:47:33AM -0700, Chris Wright wrote:
> * Alan Cox ([email protected]) wrote:
> > On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > > > Don't see why this one is a critical bug.
> > >
> > > I guess without it, modular nfsd has no syscall interface (for UML, or
> > > course).
> >
> > And the trivial zero risk fix is to compile it in. Its hardly pressing
>
> OK, let's drop it.
Dropped.
thanks,
greg k-h
On Thu, 2005-04-28 at 08:43 +0300, Kai Makisara wrote:
> On Wed, 27 Apr 2005, Alan Cox wrote:
>
> > On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > > -stable review patch. If anyone has any objections, please let us know.
> >
> > This patch is just wrong on so many different levels its hard to know
> > where to begin.
> >
> > 1. The auth for arbitary commands is CAP_SYS_RAWIO
>
> Valid complaint.
>
> > 2. "The SCSI command permissions were discussed widely on the linux
> > lists but this did not result in any useful refinement of the
> > permissions." - this is false. The process was refined, a table setup
> > was added and debugged.
>
> Any user having write access to the device is still allowed to send MODE
> SELECT (and some other commands useful for CD/DVD writers but being
> potentially dangerous to other).
If you give your user *WRITE ACCESS* to the tape you expect him to be
able to do a lot of writing, right? The restrictions for *READ* are
obviously more clear...
> OK. If the Linux solution to these kind of security problems in the not so
> central areas of kernel is to wait and see if the problem disappears
> without any action, I have to accept that. But I have tried...
the security problem is giving someone write access to a device and then
somehow expect that to mean "selective write" ?
On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > Ok thats the bit I needed to know
>
> So, do you still object to this patch being accepted?
Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
suspect but its definitely a good answer for now.
Alan
On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > Ok thats the bit I needed to know
> >
> > So, do you still object to this patch being accepted?
>
> Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> suspect but its definitely a good answer for now.
Switch it in both capable() calls in the patch? Kai, is this acceptable
to you also?
thanks,
greg k-h
On Fri, 29 Apr 2005, Greg KH wrote:
> On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> > On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > > Ok thats the bit I needed to know
> > >
> > > So, do you still object to this patch being accepted?
> >
> > Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> > suspect but its definitely a good answer for now.
>
> Switch it in both capable() calls in the patch? Kai, is this acceptable
> to you also?
>
Yes. Using CAP_SYS_ADMIN here was wrong.
--
Kai
On Sat, Apr 30, 2005 at 08:52:31AM +0300, Kai Makisara wrote:
> On Fri, 29 Apr 2005, Greg KH wrote:
>
> > On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> > > On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > > > Ok thats the bit I needed to know
> > > >
> > > > So, do you still object to this patch being accepted?
> > >
> > > Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> > > suspect but its definitely a good answer for now.
> >
> > Switch it in both capable() calls in the patch? Kai, is this acceptable
> > to you also?
> >
> Yes. Using CAP_SYS_ADMIN here was wrong.
Ok, care to send a new patch that I can use for the next -stable kernel
release?
thanks,
greg k-h
On Fri, 29 Apr 2005, Greg KH wrote:
> On Sat, Apr 30, 2005 at 08:52:31AM +0300, Kai Makisara wrote:
> > On Fri, 29 Apr 2005, Greg KH wrote:
> >
...
> > > Switch it in both capable() calls in the patch? Kai, is this acceptable
> > > to you also?
> > >
> > Yes. Using CAP_SYS_ADMIN here was wrong.
>
> Ok, care to send a new patch that I can use for the next -stable kernel
> release?
>
Sent in a different message. This patch does not restrict
usage of SCSI_IOCTL_START_UNIT and SCSI_IOCTL_STOP_UNIT. For tapes, those
mean load and unload commands. The drive status changes resulting from
these commands seem to be caught by st otherwise. I will do a patch for
-12rc later today or tomorrow. It may add changing some st status bits if
these commands succeed but that is not -stable material.
Thanks for the review for all participants.
--
Kai