tun device supplementary group ownership
Hi, It seems to me that supplementary groups should be taken into account when checking for permissions on a tun device. Can someone comment on my patch below; is it a reasonable approach? If so, I'd like to submit it for inclusion in the kernel under the GPL. Please forward any responses to me directly in addition to the lkml. Mike --- tun.c 2007-11-16 10:14:27.0 -0800 +++ tun.c.new 2007-11-21 16:12:15.0 -0800 @@ -471,7 +471,8 @@ if (((tun->owner != -1 && current->euid != tun->owner) || (tun->group != -1 && - current->egid != tun->group)) && + (current->egid != tun->group && + !groups_search(current->group_info, tun->group && !capable(CAP_NET_ADMIN)) return -EPERM; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tun device supplementary group ownership
Hi, It seems to me that supplementary groups should be taken into account when checking for permissions on a tun device. Can someone comment on my patch below; is it a reasonable approach? If so, I'd like to submit it for inclusion in the kernel under the GPL. Please forward any responses to me directly in addition to the lkml. Mike --- tun.c 2007-11-16 10:14:27.0 -0800 +++ tun.c.new 2007-11-21 16:12:15.0 -0800 @@ -471,7 +471,8 @@ if (((tun-owner != -1 current-euid != tun-owner) || (tun-group != -1 - current-egid != tun-group)) + (current-egid != tun-group + !groups_search(current-group_info, tun-group !capable(CAP_NET_ADMIN)) return -EPERM; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
group ownership of tun devices -- nonfunctional?
Per the post here: http://lkml.org/lkml/2007/6/18/228 it appears that the group ownership patch has made it into .23. I am using these patches, amongst which the kernel component appears to be identical: http://sigxcpu.org/unsorted-patches/0001-allow-tun-ownership-by-group.patch http://sigxcpu.org/unsorted-patches/tunctl_gid.diff I can create devices that are owned by my user account (tunctl -u `whoami` -t tap0) and it works fine. However, if I use group permissions with -g it stops working. In all cases, if I pass -g , the interface is created correctly but it is unusable as a non-root user. So my question is: am I doing something wrong? If I am, I don't see it. Assuming then that I am not doing anything wrong on my end, I assume then that there is something missing from the kernel patch I applied. I read over it and I can't see any issues, especially considering that tunctl comes back without error (even with -g) and creates an interface. Just wondering if this was an issue that should be looked into-- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
group ownership of tun devices -- nonfunctional?
Per the post here: http://lkml.org/lkml/2007/6/18/228 it appears that the group ownership patch has made it into .23. I am using these patches, amongst which the kernel component appears to be identical: http://sigxcpu.org/unsorted-patches/0001-allow-tun-ownership-by-group.patch http://sigxcpu.org/unsorted-patches/tunctl_gid.diff I can create devices that are owned by my user account (tunctl -u `whoami` -t tap0) and it works fine. However, if I use group permissions with -g it stops working. In all cases, if I pass -g group, the interface is created correctly but it is unusable as a non-root user. So my question is: am I doing something wrong? If I am, I don't see it. Assuming then that I am not doing anything wrong on my end, I assume then that there is something missing from the kernel patch I applied. I read over it and I can't see any issues, especially considering that tunctl comes back without error (even with -g) and creates an interface. Just wondering if this was an issue that should be looked into-- Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reclaim space from unused ramdisk?
I wonder if it would be possible to somehow reclaim space that has been previously reserved for a ramdisk without rebooting. I read the ramdisk docs in the latest kernel source and it seems that it is not currently possible. However, the kernel keeps track of the memory allocated for said ramdisks; would it not be possible with root (or even kernel) permissions to remove the flag that prevents the VM subsystem from reclaiming that space? I realize that rot permissions may not be high enough. In that case, could a module be written that takes a device name as a parameter then uses it to look up the reserved memory that device uses, then resets the necessary flag and finally unloads itself? It would have to check that the filesystem was unmounted, of course. How difficult would this be to write? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reclaim space from unused ramdisk?
I wonder if it would be possible to somehow reclaim space that has been previously reserved for a ramdisk without rebooting. I read the ramdisk docs in the latest kernel source and it seems that it is not currently possible. However, the kernel keeps track of the memory allocated for said ramdisks; would it not be possible with root (or even kernel) permissions to remove the flag that prevents the VM subsystem from reclaiming that space? I realize that rot permissions may not be high enough. In that case, could a module be written that takes a device name as a parameter then uses it to look up the reserved memory that device uses, then resets the necessary flag and finally unloads itself? It would have to check that the filesystem was unmounted, of course. How difficult would this be to write? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
