Re: [GIT PULL] Keys fixes

On Thu, Dec 17, 2015 at 8:10 PM, James Morris wrote: > > David Howells (7): > Handle leap seconds in mktime64() This one is completely wrong. Leap seconds are inserted *at* the minute, not at the secodn before the minute. So this code: + /* Handle leap seconds

Re: [GIT PULL] Keys fixes

On Fri, Dec 18, 2015 at 11:56 AM, John Stultz wrote: > > So leap-seconds are inserted at the minute, but the kernel represents > it as repeating the last second of the day. Maybe there is some reason why you want to do that, but at least from a mktime64() standpoint, it's

Re: [GIT PULL] Keys fixes

On Fri, Dec 18, 2015 at 11:46 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > The fact that people add extra code to make things extra wrong is > annoying. Side note: the key handling extra checks seem pretty pointless too. There's no reason to have those "som

Re: [GIT PULL] Keys fixes

On Fri, Dec 18, 2015 at 2:37 PM, David Howells wrote: > > Except that it has been argued that they have to be there or someone can use > dates that contribute to the signature to fake a signed content. Admittedly > being able to have a seconds=60 value in somewhere that

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 6:57 PM, Al Viro wrote: > > How would those tools know that this particular pathname _is_ a magical > symlink? Like maybe just the AFS management tools? By design you'd only run them on the mountpoint in question. Not everything has to be

Re: [GIT PULL] Keys bugfixes

On Mon, Oct 19, 2015 at 7:50 PM, James Morris wrote: > Please pull these key susbystem fixes for 4.3, per the message from David > Howells: Oops. I already pulled David's tree. Linus -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

On Tue, 6 Nov 2007, Kyle Moffett wrote: Personally I think that isspace() accepting character 0xA0 is a bug I think I agree with you. As far as the kernel is concerned, isspace() should just accept the obvious spaces (hardspace, tab, newline), and *perhaps* the VT/FF kind of things. You

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

On Wed, 7 Nov 2007, Adrian Bunk wrote: But if you want to match one character (like TOMOYO does) or want to check for printable characters except space (like Smack does) you must know whether the byte string 0xC3 0xA0 is the character à or a sequence of two characters with the second

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

On Wed, 7 Nov 2007, Adrian Bunk wrote: How should TOMOYO implement it's match one character in a pattern (used to allow or deny access in a name-based MAC)? .. I think such a design is fundamentally bogus. You don't have characters. You have bytes. So you either implement match one byte,

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

On Wed, 7 Nov 2007, Adrian Bunk wrote: Users are used to work on characters, not on bytes. Adrian, stop this idiocy. I'm not interested in listening to your soliloqui about irrelevant stuff. The kernel works on bytes. Deal with it. Stop whining. You've been told several times that all

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

On Mon, 5 Nov 2007, Ahmed S. Darwish wrote: On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote: Can we avoid string parsers in the kernel? Ok, Could someone suggest a better idea please ?. I personally think string parsers are *much* better than the alternatives (which

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Tue, 2 Oct 2007, Bill Davidsen wrote: And yet you can make the exact same case for schedulers as security, you can quantify the behavior, but if your only choice is A it doesn't help to know that B is better. You snipped a key part of the argument. Namely: Another difference is that

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Wed, 3 Oct 2007, Alan Cox wrote: Smack seems a perfectly good simple LSM module, its clean, its based upon credible security models and sound theory (unlike AppArmor). The problem with SELinux isn't the theory. It's the practice. IOW, it's too hard to use. Apparently Ubuntu is giving

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Tue, 2 Oct 2007, Bill Davidsen wrote: Unfortunately not so, I've been looking at schedulers since MULTICS, and desktops since the 70s (MP/M), and networked servers since I was the ARPAnet technical administrator at GE's Corporate RD Center. And on desktops response is (and should be

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Mon, 1 Oct 2007, James Morris wrote: Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. Hell f*cking NO! You security people are insane. I'm tired of this only my version is correct crap. The whole

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Mon, 1 Oct 2007, Stephen Smalley wrote: You argued against pluggable schedulers, right? Why is security different? Schedulers can be objectively tested. There's this thing called performance, that can generally be quantified on a load basis. Yes, you can have crazy ideas in both

Re: Adding a security parameter to VFS functions

On Wed, 15 Aug 2007, David Howells wrote: Would you object greatly to functions like vfs_mkdir() gaining a security parameter? What I'm thinking of is this: int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode, struct security *security) I