Re: CVS commit: src/sys/netinet6
On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: have you checked callers and ensure that the change from EACCES to EPERM won't be a problem? Only ipsec_set_policy() returns EPERM instead of EACCES now, and I don't think it should be a problem. don't think? why not? i asked if you checked what the callers of ipsec_set_policy do with the error number. do you mean yes, of course? As for calling context -- I did look at the callers and mostly I just moved the call inside instead of at the top. That's also why I didn't remove the last one in in6.c, where is obvious that it's done before splnet(), and still need to take care of it. :) i'm not sure what you mean. my question was about the ipsec.c change. sorry if it was not clear. It's possible though that I've missed something. Do you see any problems? i don't know if there are problems or not. i'm not familiar with the code in question. i was just wondering about the implications of the error number change. Okay, I misunderstood you. I thought you were asking about the calling context *and* the error value. Anyway, the error value is just returned. The caller returns it if it's not zero. I could not find a place that checks specifically for EACCES, or documentation that says the user should check for it. Ioctl(4) doesn't mention it at all. That said, where we now return EPERM is where in the future we'll return the error value returned by kauth(9), like many many other places in the kernel. Other parts of the networking stacks (say, opening a raw socket) now return EPERM instead of EACCES -- if we're interested in checking whether this is a problem or not we should do so on a much larger scale, and not as a response to a specific change. Thanks, -e.
Re: CVS commit: src/sys/netinet6
hi, On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: have you checked callers and ensure that the change from EACCES to EPERM won't be a problem? Only ipsec_set_policy() returns EPERM instead of EACCES now, and I don't think it should be a problem. don't think? why not? i asked if you checked what the callers of ipsec_set_policy do with the error number. do you mean yes, of course? As for calling context -- I did look at the callers and mostly I just moved the call inside instead of at the top. That's also why I didn't remove the last one in in6.c, where is obvious that it's done before splnet(), and still need to take care of it. :) i'm not sure what you mean. my question was about the ipsec.c change. sorry if it was not clear. It's possible though that I've missed something. Do you see any problems? i don't know if there are problems or not. i'm not familiar with the code in question. i was just wondering about the implications of the error number change. Okay, I misunderstood you. I thought you were asking about the calling context *and* the error value. Anyway, the error value is just returned. The caller returns it if it's not zero. I could not find a place that checks specifically for EACCES, or documentation that says the user should check for it. Ioctl(4) doesn't mention it at all. ok. That said, where we now return EPERM is where in the future we'll return the error value returned by kauth(9), like many many other places in the kernel. Other parts of the networking stacks (say, opening a raw socket) now return EPERM instead of EACCES ip(4) and ip6(4) seem to document EACCES. -- if we're interested in checking whether this is a problem or not we should do so on a much larger scale, and not as a response to a specific change. i'm not sure what you mean. how can we check breakage without looking at each specific changes? YAMAMOTO Takashi Thanks, -e.
Re: CVS commit: src/sys
hi, Module Name: src Committed By: elad Date: Wed May 6 21:41:59 UTC 2009 Modified Files: src/sys/netinet: ip_output.c src/sys/netinet6: ip6_output.c ip6_var.h ipsec.c ipsec.h raw_ip6.c udp6_output.c Log Message: Remove some usage of priv and privileged variables and instead pass around credentials. Also push down kauth(9) calls closer to where the operation is done. Mailing list reference: http://mail-index.netbsd.org/tech-net/2009/04/30/msg001270.html To generate a diff of this commit: cvs rdiff -u -r1.201 -r1.202 src/sys/netinet/ip_output.c cvs rdiff -u -r1.137 -r1.138 src/sys/netinet6/ip6_output.c cvs rdiff -u -r1.52 -r1.53 src/sys/netinet6/ip6_var.h cvs rdiff -u -r1.140 -r1.141 src/sys/netinet6/ipsec.c cvs rdiff -u -r1.50 -r1.51 src/sys/netinet6/ipsec.h cvs rdiff -u -r1.103 -r1.104 src/sys/netinet6/raw_ip6.c isn't KAUTH_REQ_NETWORK_SOCKET_RAWSOCK being deprecated in favor of _OPEN? YAMAMOTO Takashi cvs rdiff -u -r1.38 -r1.39 src/sys/netinet6/udp6_output.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys
On Sun, May 10, 2009 at 1:16 PM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: isn't KAUTH_REQ_NETWORK_SOCKET_RAWSOCK being deprecated in favor of _OPEN? I'm still trying to decide, that's why I used this one (so removing it causes errors). On one hand, it would be nice to centralize everything like we planned. On the other hand, it requires the secmodel to understand kernel internals until things are done right (ie., we get rid of the nasty things like the routing socket) and I don't want to have to put the same logic in every secmodel just so that the system works. I have plans on fixing the bluetooth socket for this (based on socket credentials), and might add an open routing socket request or something. At the moment it's at a lower priority. -e.
Re: CVS commit: src/sys/netinet6
On Sun, May 10, 2009 at 1:12 PM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
That said, where we now return EPERM is where in the future we'll
return the error value returned by kauth(9), like many many other
places in the kernel. Other parts of the networking stacks (say,
opening a raw socket) now return EPERM instead of EACCES
ip(4) and ip6(4) seem to document EACCES.
Right. Do you think we need to fix the code or the documentation?
IMHO - documentation. I like being able to tell when an error comes
from kauth(9), and EPERM is a nice way to paint those.
-- if we're
interested in checking whether this is a problem or not we should do
so on a much larger scale, and not as a response to a specific change.
i'm not sure what you mean.
how can we check breakage without looking at each specific changes?
Ideally, regression tests and documentation on what parts of the
system affect other parts and how, including documentation.
Examples:
- IPKDB doesn't compile and not included in ALL (I think we need to
use x86_{read,write}_flags() on i386, but don't take my word for it)
- errno(2) says, for EMFILE, that [a]s released, the limit on the
number of open files per process is 64 -- is this still correct?
But I guess looking at each specific change is good enough for now. ;)
Thanks,
-e.
Re: CVS commit: src/sys/nfs
hi, On Sun, May 10, 2009 at 05:18:26AM +, YAMAMOTO Takashi wrote: Module Name: src Committed By: yamt Date: Sun May 10 05:18:26 UTC 2009 Modified Files: src/sys/nfs: nfs_vnops.c Log Message: nfs_lookup: vn_lock the vnode returned by cache_lookup_raw before feeding it to VOP_GETATTR. it's necessary because the vnode might be being cleaned by getcleanvnode. it's an instance of more general races between vnode reclaim and unlocked VOPs. however, this one happens somewhat often because it can be triggered by getnewvnode rather than revoke. This seems a bit odd; cache_lookup_raw returns a reference to the vnode, so the vnode shouldn't *be* getting reclaimed after that. Or so I'd think. (?) there is a race. see PR/41374. besides that, a vnode reference does not prevent revoke(2). YAMAMOTO Takashi -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
Simon Burge sim...@netbsd.org writes: Perry E. Metzger wrote: [ ... ] Encrypted swap should be the default -- either using cgd or by simply encrypting the blocks as they go in and out without using the cgd layer. You've benchmarked the effect of this, especially on older hardware? No, but others have, and it is generally negligible. Why is this the case? Well, think about it for a moment -- the time to encrypt a disk block is a tiny fraction of the time needed to write it to disk. It is true that on older machines there is less processor, but there is also even less disk bandwidth. The situation is a lot worse if you're thrashing, but of course the situation is always a lot worse if you're thrashing. In any case: there would clearly be a knob to this on and off, and it can even be left off by default, at least on older ports. The problem is this: it is a significant effort to set this up at all, so no one does it. If it was trivial to set up, even something listed in sysinst, it would be widely used, unlike the situation now where it is barely if ever done. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/sys/dist/ipf/netinet
Mihai Chelaru wrote: Module Name:src Committed By: kefren Date: Fri May 8 05:18:34 UTC 2009 Modified Files: src/sys/dist/ipf/netinet: ip_fil_netbsd.c Log Message: Don't call callout_stop() without callout_init() Fixes PR/41364 To generate a diff of this commit: cvs rdiff -u -r1.49 -r1.50 src/sys/dist/ipf/netinet/ip_fil_netbsd.c Will this be pulled up to NetBSD 5.0? Thanks, -e.
Re: CVS commit: src/sbin/fsck_ffs
On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: have you tried to convince freebsd guys to use your preferred name? being different creates another layer of confusion. We had a short discussion about this during BSDCan. Kirk didn't mind and if it should be reasonable to get consistent. Joerg
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: [...] since there's no way of changing a PGP passphrase short of generating a new key. Huh? Sure, you have a need to deal with keyring copies from before the change, maybe with some more rm -P and its limtations, but otherwise, I don't understand this. -- Dan. pgpNspqO3Rna0.pgp Description: PGP signature
Re: CVS commit: src/sbin/fsck_ffs
In message: 20090510220227.gd16...@britannica.bec.de Joerg Sonnenberger jo...@britannica.bec.de writes: : On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: : have you tried to convince freebsd guys to use your preferred name? : being different creates another layer of confusion. : : We had a short discussion about this during BSDCan. Kirk didn't mind and : if it should be reasonable to get consistent. I think that this sort of decision can't be made by just Kirk since FreeBSD has deployed ufs2 for several releases now. I've missed much of the discussion, can someone recap exactly what you'd like to see changed? That would be the starting point for any user-visisble changes to FreeBSD... Warner
Re: CVS commit: src/sbin/fsck_ffs
On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote: I've missed much of the discussion, can someone recap exactly what you'd like to see changed? That would be the starting point for any user-visisble changes to FreeBSD... There is currently a mixed naming convention when refering to FFS filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc. The consensus in NetBSD was to consistently use FFS and FFSv2. UFS2 is bad, as it changes the underlaying inode format, but still has FFS on top. Joerg
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote: On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: [...] since there's no way of changing a PGP passphrase short of generating a new key. Huh? Sure, you have a need to deal with keyring copies from before the change, maybe with some more rm -P and its limtations, but otherwise, I don't understand this. Sorry, I must be missing something then (perfectly possible, now I'm old and grey) - how do you change the passphrase on a PGP key? For gpg, the passwd sub-command under edit-key. For other implementations, special sigils created by waving the magic wand^Wpointer. If the corresponding feature is missing from this implementation, that's a deficiency, but not a limitation of the format. Someone might implement the feature, or you might combine tools since the keyring format is standardised and (I hope) therefore the tools are interoperable. -- Dan. pgpab5DcKPMca.pgp Description: PGP signature
Re: CVS commit: src/sbin/fsck_ffs
In message: 20090511015855.gd16...@britannica.bec.de Joerg Sonnenberger jo...@britannica.bec.de writes: : On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote: : I've missed much of the discussion, can someone recap exactly what : you'd like to see changed? That would be the starting point for any : user-visisble changes to FreeBSD... : : There is currently a mixed naming convention when refering to FFS : filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc. : The consensus in NetBSD was to consistently use FFS and FFSv2. : UFS2 is bad, as it changes the underlaying inode format, but still has : FFS on top. Right, I gleaned that from the discussion. What I didn't glean from the discussion is what, exactly, you were going to do about it and what, exactly, you'd like to harmonize with FreeBSD on. It may have been there, but I just missed it. Warner
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 12:11:03PM +1000, Daniel Carosone wrote: On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote: On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote: On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote: [...] since there's no way of changing a PGP passphrase short of generating a new key. Huh? Sure, you have a need to deal with keyring copies from before the change, maybe with some more rm -P and its limtations, but otherwise, I don't understand this. Sorry, I must be missing something then (perfectly possible, now I'm old and grey) - how do you change the passphrase on a PGP key? For gpg, the passwd sub-command under edit-key. For other implementations, special sigils created by waving the magic wand^Wpointer. If the corresponding feature is missing from this implementation, that's a deficiency, but not a limitation of the format. Someone might implement the feature, or you might combine tools since the keyring format is standardised and (I hope) therefore the tools are interoperable. Cool, thanks, that's exactly the information I was looking for. I'll look into providing that somehow (I've been of the opinion that we need one binary for key management, and one binary for signing/verification and encrypting/decrypting for a while now - it's the way that the old nbpg SoC project was going too), and that definitely gives me an incentive to do that kind of split. Thanks once again, Al
re: CVS commit: src/share/man/man4
On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote: So really should simply document the option DRM_NO_AGP rather than telling folks to include unnecessary drivers! Just because it compiles doesn't mean it works properly. For most drivers at least, you really need the AGP support for the GART. what about systems that don't have AGP? .mrg.
