Re: Mis-Design of Btrfs?
Alasdair == Alasdair G Kergon a...@redhat.com writes: Alasdair On Thu, Jul 14, 2011 at 04:38:36PM +1000, Neil Brown wrote: It might make sense for a device to be able to report what the maximum 'N' supported is... that might make stacked raid easier to manage... Alasdair I'll just say that any solution ought to be stackable. I've been mulling this over too and wondering how you'd handle this, because upper layers really can't peak down into lower layers easily. As far as I understand things. So if you have btrfs - luks - raid1 - raid6 - nbd - remote disks How does btrfs handle errors (or does it even see them!) from the raid6 level when a single nbd device goes away? Or taking the original example, when btrfs notices a checksum isn't correct, how would it push down multiple levels to try and find the correct data? Alasdair This means understanding both that the number of data access Alasdair routes may vary as you move through the stack, and that this Alasdair number may depend on the offset within the device. It almost seems to me that the retry needs to be done at each level on it's own, without pushing down or up the stack. But this doesn't handle the wrong file checksum issue. Hmm... maybe instead of just one number, we need another to count the levels down you go (or just split 16bit integer in half, bottom half being count of tries, the upper half being levels down to try that read?) It seems to defeat the purpose of layers if you can go down and find out how many layers there are underneath you John -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation
Eric == Eric Paris epa...@redhat.com writes: Eric SELinux would like to implement a new labeling behavior of newly Eric created inodes. We currently label new inodes based on the Eric parent and the creating process. This new behavior would also Eric take into account the name of the new object when deciding the Eric new label. This is not the (supposed) full path, just the last Eric component of the path. Eric This is very useful because creating /etc/shadow is different Eric than creating /etc/passwd but the kernel hooks are unable to Eric differentiate these operations. We currently require that Eric userspace realize it is doing some difficult operation like that Eric and than userspace jumps through SELinux hoops to get things set Eric up correctly. This patch does not implement new behavior, that Eric is obviously contained in a seperate SELinux patch, but it does Eric pass the needed name down to the correct LSM hook. If no such Eric name exists it is fine to pass NULL. I've looked this patch over, and maybe I'm missing something, but how does knowing the name of the file really tell you anything, esp when you only get the filename, not the path? What threat are you addressing with this change? So what happens when I create a file /home/john/shadow, does selinux (or LSM in general) then run extra checks because the filename is 'shadow' in your model? I *think* the overhead shouldn't be there if SELINUX is disabled, but have you confirmed this? How you run performance tests before/after this change when doing lots of creations of inodes to see what sort of performance changes might be there? Thanks, John -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation
Eric == Eric Paris epa...@redhat.com writes: Eric On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: Eric == Eric Paris epa...@redhat.com writes: So what happens when I create a file /home/john/shadow, does selinux (or LSM in general) then run extra checks because the filename is 'shadow' in your model? Eric It's entirely a question of labeling and one that was discussed on the Eric LSM list in some detail: Eric http://marc.info/?t=12914130822r=1w=2 Thank you for pointing me at this discussion. I'm working my way through it, but so far I'm not seeing any consensus that this is really the proper thing to do. I personally feel this should be in userspace if at all possible. Eric The basic synopsis is that when a new inode is created SELinux Eric must apply some label. It makes the decision for what label to Eric apply based on 3 pieces of information. Eric The label of the parent inode. Eric The label of the process creating the new inode. Eric The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc These seem to be ok, if you're using label based security. But since I freely admit I'm not an expert or even a user, I'm just trying to understand and push back to make sure we do what's good. And which doesn't impact non-SElinux users. Eric This patch adds a 4th piece of information, the name of the Eric object being created. An obvious situation where this will be Eric useful is devtmpfs (although you'll find other examples in the Eric above thread). devtmpfs when it creates char/block devices is Eric unable to distinguish between kmem and console and so they are Eric created with a generic label. hotplug/udev is then called which Eric does some pathname like matching and relabels them to something Eric more specific. We've found that many people are able to race Eric against this particular updating and get spurious denials in Eric /dev. With this patch devtmpfs will be able to get the labels Eric correct to begin with. So your Label based access controls are *also* based on pathnames? Right? Eric I'm certainly willing to discuss the security implications of this Eric patch, but that would probably be best done with a significantly Eric shortened cc-list. You'll see in the above mentioned thread that a Eric number of 'security' people (even those who are staunchly anti-SELinux) Eric recognize there is value in this and that it is certainly much better Eric than we have today. I *think* the overhead shouldn't be there if SELINUX is disabled, but have you confirmed this? How you run performance tests before/after this change when doing lots of creations of inodes to see what sort of performance changes might be there? Eric I've actually recently done some perf testing on creating large Eric numbers of inodes using bonnie++, since SELinux was a noticeable Eric overhead in that operation. Doing that same test with SELinux Eric disabled (or enabled) I do not see a noticeable difference when Eric this patch is applied or not. It's just an extra argument to a Eric function that goes unused. That answers alot of my concerns then. Not having it impact users in a non-SELinux context is vitally important to me. Thanks, John -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
