[9fans] lpdaemon
in /sys/src/cmd/lp/lpdaemon.c:297,310 These info.host[strlen(info.host)] = '\0'; … info.user[strlen(info.user)] = '\0'; look nonsence as zeros are placed exactly where they already are. Should read as in following instead: info.host[NAMELEN] = '\0'; … info.user[NAMELEN] = '\0'; shoudn't it?
Re: [9fans] lpdaemon
i agree ... applied to 9atom. Subject: [sources] applied patch: /n/atom/patch/applied/lpdaemonnit Reply-To: sour...@9atom.org email quans...@quanstro.net readme >From: yaroslav >Subject: [9fans] lpdaemon in /sys/src/cmd/lp/lpdaemon.c:297,310 These info.host[strlen(info.host)] = '\0'; … info.user[strlen(info.user)] = '\0'; look nonsence as zeros are placed exactly where they already are. Should read as in following instead: info.host[NAMELEN] = '\0'; … info.user[NAMELEN] = '\0'; removed files /sys/src/cmd/lp/lpdaemon.c lpdaemon.c /sys/src/cmd/lp/lpdaemon.c lpdaemon.c lpdaemon.c.orig:299,305 - lpdaemon.c:299,305 strncpy(info.host, "unknown", NAMELEN); else strncpy(info.host, (const char *)&ap[1], NAMELEN); - info.host[strlen(info.host)] = '\0'; + info.host[NAMELEN] = '\0'; break; case 'P': if (ap[1] == '\0') lpdaemon.c.orig:306,312 - lpdaemon.c:306,312 strncpy(info.user, "unknown", NAMELEN); else strncpy(info.user, (const char *)&ap[1], NAMELEN); - info.user[strlen(info.user)] = '\0'; + info.user[NAMELEN] = '\0'; break; } } -- merge...backup...copy... cpfile lpdaemon.c /n/dist/sys/src/cmd/lp/lpdaemon.c # remove these files if you want. I will not remove them for you # ($patch/undo will not restore them) done
Re: [9fans] lpdaemon
The first opportunity to write a nil byte should always be taken. Using sizeof only means that in corner cases memory disclosure may occur between where the nil should be and the end of the array. While this isn't a security critical app, it is still good coding practice. x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; info.host[x] = 0; D On Jun 5, 2013, at 5:38 AM, yaroslav wrote: > in /sys/src/cmd/lp/lpdaemon.c:297,310 > > These >info.host[strlen(info.host)] = '\0'; >… >info.user[strlen(info.user)] = '\0'; > > look nonsence as zeros are placed exactly where they already are. > Should read as in following instead: > >info.host[NAMELEN] = '\0'; >… >info.user[NAMELEN] = '\0'; > > shoudn't it? > >
Re: [9fans] lpdaemon
On Wed Jun 5 09:15:11 EDT 2013, don.bai...@gmail.com wrote: > The first opportunity to write a nil byte should always be taken. > Using sizeof only means that in corner cases memory disclosure may > occur between where the nil should be and the end of the array. While > this isn't a security critical app, it is still good coding practice. > > x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; > info.host[x] = 0; let's start at the beginning. strncpy is not good coding practice. and lpdaemon is not well written by today's standards. ☺ however, unless i'm missing something, the code has exactly that. /sys/src/cmd/lp/lpdaemon.c:297,310 case 'H': if (ap[1] == '\0') strncpy(info.host, "unknown", NAMELEN); else strncpy(info.host, (const char *)&ap[1], NAMELEN); info.host[NAMELEN] = '\0'; break; case 'P': if (ap[1] == '\0') strncpy(info.user, "unknown", NAMELEN); else strncpy(info.user, (const char *)&ap[1], NAMELEN); info.user[NAMELEN] = '\0'; break; - erik
Re: [9fans] lpdaemon
I think your code is wrong. If the NUL byte is present, it doesn't do anything, however if it is not there, strlen will read more than it should, and possibly try to read some invalid address. In case info.host is a fixe size array, a simple info.host[sizeof info.host - 1] = 0; would do. Am 05.06.2013 15:13, schrieb Don Bailey: > The first opportunity to write a nil byte should always be taken. Using > sizeof only means that in corner cases memory disclosure may occur between > where the nil should be and the end of the array. While this isn't a security > critical app, it is still good coding practice. > > x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; > info.host[x] = 0; > > D >
Re: [9fans] lpdaemon
You're absolutely correct if the length of value to be copied is not validated prior to the copy. Then, an invalid page could be hit if no nil is present within the array or beyond. I wasn't providing a verbatim patch (notice the function and operator weren't filled in). I was just providing the sequence of events that should occur. Eric points out correctly that strncpy effectively performs the first operation on the user's behalf. The second is achieved through the write to N. To be verbose, my bypassing of strncpy is due to issues I've encountered in multi-threaded code. e.g. Don't trust libc copy functions in MT envs, always check post call. An interesting and sometimes desirable effect of crashing on an invalid page read is that if memory can be corrupted, a consistent unexploitable crash is better than entering a context where the bug becomes exploitable. D On Jun 5, 2013, at 7:38 AM, Friedrich Psiorz wrote: > I think your code is wrong. If the NUL byte is present, it doesn't do > anything, however if it is not there, strlen will read more than it > should, and possibly try to read some invalid address. > In case info.host is a fixe size array, a simple > info.host[sizeof info.host - 1] = 0; > would do. > > Am 05.06.2013 15:13, schrieb Don Bailey: >> The first opportunity to write a nil byte should always be taken. Using >> sizeof only means that in corner cases memory disclosure may occur between >> where the nil should be and the end of the array. While this isn't a >> security critical app, it is still good coding practice. >> >> x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; >> info.host[x] = 0; >> >> D > >
Re: [9fans] lpdaemon
Not exactly. But, functionally close enough. I skipped commenting on strncpy to ignore the plethora of issues with lpd and focus on the question at hand. D On Jun 5, 2013, at 7:20 AM, erik quanstrom wrote: > On Wed Jun 5 09:15:11 EDT 2013, don.bai...@gmail.com wrote: >> The first opportunity to write a nil byte should always be taken. >> Using sizeof only means that in corner cases memory disclosure may >> occur between where the nil should be and the end of the array. While >> this isn't a security critical app, it is still good coding practice. >> >> x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; >> info.host[x] = 0; > > let's start at the beginning. strncpy is not good coding practice. > and lpdaemon is not well written by today's standards. ☺ > > however, unless i'm missing something, the code has exactly that. > > /sys/src/cmd/lp/lpdaemon.c:297,310 >case 'H': >if (ap[1] == '\0') >strncpy(info.host, "unknown", NAMELEN); >else >strncpy(info.host, (const char *)&ap[1], NAMELEN); >info.host[NAMELEN] = '\0'; >break; >case 'P': >if (ap[1] == '\0') >strncpy(info.user, "unknown", NAMELEN); >else >strncpy(info.user, (const char *)&ap[1], NAMELEN); >info.user[NAMELEN] = '\0'; >break; > > - erik >
Re: [9fans] lpdaemon
> You're absolutely correct if the length of value to be copied is not > validated prior to the copy. Then, an invalid page could be hit if no > nil is present within the array or beyond. wrong. strncpy only copies up to the specified maximum. the code is ugly but correct. > To be verbose, my bypassing of strncpy is due to issues I've > encountered in multi-threaded code. e.g. Don't trust libc copy > functions in MT envs, always check post call. this sounds like your saying that because you had trouble in a multithreaded unix application, then without examining the code at hand, it is pronounced to have the same issue. that sounds like equivocation to me. the code is correct. and in all cases nul-terminated, and any unused bytes are 0. i only object to strncpy because it requires extra work. seprint, snprint are a bit heavy weight but tend to produce cleaner looking code. ymmv. - erik
Re: [9fans] lpdaemon
You get that I'm talking about the subsequent read back after copy, right? No need to be so competitive :) Also, you're making strange presumptions about me having presumptions. I'm not trying to say you're wrong or a poor coder, Erik. I was simply offering my point of view. Before this thread dissolves into typical Plan 9 waste I'll admit that my first mistake was to make the poor decision to reply to a 9fans email. D On Jun 5, 2013, at 8:09 AM, erik quanstrom wrote: >> You're absolutely correct if the length of value to be copied is not >> validated prior to the copy. Then, an invalid page could be hit if no >> nil is present within the array or beyond. > > wrong. strncpy only copies up to the specified maximum. > the code is ugly but correct. > >> To be verbose, my bypassing of strncpy is due to issues I've >> encountered in multi-threaded code. e.g. Don't trust libc copy >> functions in MT envs, always check post call. > > this sounds like your saying that because you had trouble in > a multithreaded unix application, then without examining the > code at hand, it is pronounced to have the same issue. > > that sounds like equivocation to me. the code is correct. > and in all cases nul-terminated, and any unused bytes are > 0. > > i only object to strncpy because it requires extra work. seprint, > snprint are a bit heavy weight but tend to produce cleaner looking > code. ymmv. > > - erik >
[9fans] Hardware recommandations for new CPU and file servers
I want to replace my CPU and file servers. I don't need much performance, a new Atom is more than enough, but I'd like something that supports at least 8GB RAM. This board seems nice: http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm. Where to put it though? I want something completely silent. Think Soekris but 64 bit and with a faster CPU. That means no PSU fan. Low power Atom boards consume less power than laptops, I don't understand why nobody seems to produce a design that does not use a fan for the PSU. The CPU servers will be diskless, but for the file server I'd like something that can fit a few drives. That means more than two. Four would be ideal. I am not limited to that board nor to Atom CPUs. I am curious what other 9fans use or would like to use. Thanks. -- Aram Hăvărneanu
Re: [9fans] Hardware recommandations for new CPU and file servers
On Wed Jun 5 14:53:56 EDT 2013, ara...@mgk.ro wrote: > I want to replace my CPU and file servers. I don't need much > performance, a new Atom is more than enough, but I'd like something > that supports at least 8GB RAM. This board seems nice: > http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm. iirc, this motherboard only supports xhci usb, so that might be an issue. - erik
Re: [9fans] Hardware recommandations for new CPU and file servers
is anyone working on a xhci driver? or is anyone willing to send hardware so someone who's willing will write a driver for it? -- cinap
Re: [9fans] Hardware recommandations for new CPU and file servers
On Wed Jun 5 15:49:12 EDT 2013, cinap_len...@gmx.de wrote: > is anyone working on a xhci driver? or is anyone willing to send hardware > so someone who's willing will write a driver for it? send me an address. how many boards do you want? - erik
Re: [9fans] Hardware recommandations for new CPU and file servers
I use Supermicro 5015A-EHF-D525 1U servers in a 19" cabinet. they are fairly quiet. you can usually find reasonably priced used 12U or 24U cabinets at places like RE-PC. i've not found a good way of mounting Sheeva and RPi cpu's in the cabinet. On Wed, Jun 5, 2013 at 11:52 AM, Aram Hăvărneanu wrote: > I want to replace my CPU and file servers. I don't need much > performance, a new Atom is more than enough, but I'd like something > that supports at least 8GB RAM. This board seems nice: > http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm. > > Where to put it though? > > I want something completely silent. Think Soekris but 64 bit and > with a faster CPU. That means no PSU fan. Low power Atom boards > consume less power than laptops, I don't understand why nobody seems > to produce a design that does not use a fan for the PSU. The CPU > servers will be diskless, but for the file server I'd like something > that can fit a few drives. That means more than two. Four would be > ideal. > > I am not limited to that board nor to Atom CPUs. I am curious what > other 9fans use or would like to use. Thanks. > > -- > Aram Hăvărneanu > >
Re: [9fans] Hardware recommandations for new CPU and file servers
awesome! can you ship to germany? i'll see when i can schedule vacation so i have the time :) -- cinap
Re: [9fans] Hardware recommandations for new CPU and file servers
On Wed Jun 5 16:37:05 EDT 2013, cinap_len...@gmx.de wrote: > awesome! can you ship to germany? i'll see when i can schedule vacation > so i have the time :) ich kanns mir ausrechnen. - erik
Re: [9fans] Hardware recommandations for new CPU and file servers
For something low power you can use an external power brick and a "picoPSU" DC-DC converter with 12V in and 5V + 12V out with appropriate connectors. Check out mini-itx.com. Fanless power supplies are also available upto about 480W. Though I don't worry about fan noise as my fileserver is not too far from a somewhat noisy 'frig! The FS is a standad tower case that can hold 8 disks (holds 6 now). It has large fans that are mostly silent. On Jun 5, 2013, at 11:52 AM, Aram Hăvărneanu wrote: > I want to replace my CPU and file servers. I don't need much > performance, a new Atom is more than enough, but I'd like something > that supports at least 8GB RAM. This board seems nice: > http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm. > > Where to put it though? > > I want something completely silent. Think Soekris but 64 bit and > with a faster CPU. That means no PSU fan. Low power Atom boards > consume less power than laptops, I don't understand why nobody seems > to produce a design that does not use a fan for the PSU. The CPU > servers will be diskless, but for the file server I'd like something > that can fit a few drives. That means more than two. Four would be > ideal. > > I am not limited to that board nor to Atom CPUs. I am curious what > other 9fans use or would like to use. Thanks. > > -- > Aram Hăvărneanu >
Re: [9fans] Hardware recommandations for new CPU and file servers
I bought a SuperMicro X7SLA-H a few years ago, 2 1.6Ghz Atoms with 2xGbE, though only 2GB of RAM. This is my home auth/cpu/file server. I am very happy with it, it does have a small fan for the glue logic chip but the cpu is passively cooled. I have this in an mini-ITX case with a pair or mirrored SATA-3 Enterprise disks; It draws about 25W. You probably cannot buy these any more but I am sure there is somthing similar now. I thought must new Atom MBs didn't need fans due to newer technology chipsets? -Steve
Re: [9fans] Hardware recommandations for new CPU and file servers
+1 to this, though I use a different chassis. Since I'm relegated to an apartment at the moment, I have a desktop rack mounted in a closet. My development boards are set on top of the cabinet with 6-32 1/2" standoffs, which rest on an ESD mat grounded to the rack. It's small, but gives me about 8U worth of space in cramped quarters. On Wed, Jun 5, 2013 at 1:09 PM, Skip Tavakkolian wrote: > I use Supermicro 5015A-EHF-D525 1U servers in a 19" cabinet. they are > fairly quiet. you can usually find reasonably priced used 12U or 24U > cabinets at places like RE-PC. > > i've not found a good way of mounting Sheeva and RPi cpu's in the cabinet. > > > > > > > > On Wed, Jun 5, 2013 at 11:52 AM, Aram Hăvărneanu wrote: > >> I want to replace my CPU and file servers. I don't need much >> performance, a new Atom is more than enough, but I'd like something >> that supports at least 8GB RAM. This board seems nice: >> http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm. >> >> Where to put it though? >> >> I want something completely silent. Think Soekris but 64 bit and >> with a faster CPU. That means no PSU fan. Low power Atom boards >> consume less power than laptops, I don't understand why nobody seems >> to produce a design that does not use a fan for the PSU. The CPU >> servers will be diskless, but for the file server I'd like something >> that can fit a few drives. That means more than two. Four would be >> ideal. >> >> I am not limited to that board nor to Atom CPUs. I am curious what >> other 9fans use or would like to use. Thanks. >> >> -- >> Aram Hăvărneanu >> >> >
Re: [9fans] Fossil disk usage over 100%?
>> Richard mentioned fixing the snapshots bug in fossil. This >> is about as close as we've come to examining the technical >> issues. > > No: this *is* examining the technical issues. Richard has done > actual engineering here; it's moderately depressing that many > members of this list, and particularly some of the more vocal, > don't seem able to recognize the difference. About as close as we've come to examining the technical issues in this thread. The context of my observation was the continuing cascade of vague recriminations. I don't think I was that unclear. I am however losing track of who is defending what. I'll stop attempting to moderate. -sl
Re: [9fans] Fossil disk usage over 100%?
>> Richard mentioned fixing the snapshots bug in fossil. This >> is about as close as we've come to examining the technical >> issues. > > No: this *is* examining the technical issues. Richard has done > actual engineering here; it's moderately depressing that many > members of this list, and particularly some of the more vocal, > don't seem able to recognize the difference. About as close as we've come to examining the technical issues in this thread. The context of my observation was the continuing cascade of vague recriminations. I don't think I was that unclear. I am however losing track of who is defending what. I'll stop attempting to moderate. -sl
[9fans] u9fs fix for OSX
Hello, OSX unicodes for some japanese letters are irregular. current u9fs fails to handle OSX unicode correctly. you will find u9fs that fix the problem at http://plan9.aichi-u.ac.jp/netlib/ probably anyone except japanese will not be interested in, though. Kenji Arisawa
Re: [9fans] Hardware recommandations for new CPU and file servers
> I don't understand why nobody seems > to produce a design that does not use a fan for the PSU In the same league, I was looking for an uninterruptable PSU and found a single supplier and a price tag, for a single host of >USD 340. Fanless, I must concede, but then the Li-Ion batteries weren't included. Something out there is odd, these are features every laptop gets from the get-go. ++L
Re: [9fans] Hardware recommandations for new CPU and file servers
On Jun 6, 2013, at 1:17, lu...@proxima.alt.za wrote: >> I don't understand why nobody seems >> to produce a design that does not use a fan for the PSU > > In the same league, I was looking for an uninterruptable PSU and found > a single supplier and a price tag, for a single host of >USD 340. > Fanless, I must concede, but then the Li-Ion batteries weren't > included. > > Something out there is odd, these are features every laptop gets from > the get-go. > > ++L Build a psu for my fileserver that has battery back up. It isn't fanless (honestly sounds like a jet taking off) but I have all of those fancy laptop features with about $100. If you have the know how building a psu is the way to go sometimes. Veety
Re: [9fans] Hardware recommandations for new CPU and file servers
> Build a psu for my fileserver that has battery back up. It isn't > fanless (honestly sounds like a jet taking off) but I have all of > those fancy laptop features with about $100. If you have the know > how building a psu is the way to go sometimes. Can you suggest a source for the construction details? I thought I'd searched the web pretty thoroughly and came up empty-handed. Of course, a UPS+PSU makes so little sense... ++L
Re: [9fans] Hardware recommandations for new CPU and file servers
On Thu, 06 Jun 2013 07:17:36 +0200 lu...@proxima.alt.za wrote: > In the same league, I was looking for an uninterruptable PSU and found > a single supplier and a price tag, for a single host of >USD 340. > Fanless, I must concede, but then the Li-Ion batteries weren't > included. UPSes come in a wide variety. A mate of mine manufacturers 500KVA commercial UPSes that can set you back upwards of $100K. And you can also buy a 600VA capacity UPS from Amazon for $50. What capacity and features were you looking for? Typical computer UPSes use lead-acid batteries which are much cheaper than Li-Ion. You can get a 12V 8Ah replacement battery for about $15 and up.
Re: [9fans] Hardware recommandations for new CPU and file servers
> What capacity and features were you looking for? I'm looking to eliminate the 220V circuit between UPS and PSU altogether, I believe it to be archaic and inefficient. I'm also looking for multiple inputs, so that eventually it will be possible to connect the PSU directly to solar panels as well as to any available generator (this is Africa: lots of sun, but the demand for electricity outstrips the supply). I've done some homework and I'm not happy with commercial offerings as available here. I'm looking for a circuit that can be built by an amateur and will power a single conventional desktop computer (let's say 300W), while at the same time it can be scaled to supply as many such desktops as needed. Given the handful of DC supplies required by the average motherboard, the idea of stacking PSUs makes a lot of sense to me. A bit off topic, though. ++L
