Well, you see, that's the problem... Management refuses to let me implement a solution that's not supported, and as soon as I go and compile Samba custom, I lose the ability to call Redhat for support.
Yeah, I figured this. This is very common. Are you using the latest RHEL package available though? RHEL3 ships with a version poor version of Samba (like 3.0.0rcXXX or something). I've had tons of problems with it. You can get pretty much the newest version from RedHat though.
Even the Samba team has realized that OpenLDAP sucks and has started writing their own LDAP implementation for Samba 4 (look in the roadmap, you'll see it's in there, but not yet started or written yet).:-) This is not why. The problem is LDAP interoperability. OpenLDAP strives for compliance to the LDAP RFCs. Samba strives for interop with Windows. Microsoft's LDAP server does not obey the LDAP RFCs in a number of important ways. It's all pretty obscure, but suffice to say that without implementing our own LDAP server, we could never get great Active Directory interop.
Also, did you have to compile Samba with IBM's LDAP libraries to make it work properly?
Nope. It should work out of the box.
Because I know they'd probably throw it back in my face and say it's unreproduceable since who wants to install Iplanet Directory Server and set up a whole PDC + Windows XP client just to reproduce the bug?
Nope, we don't do that:-) We've taken bug reports that require mainframes, metaframe client, OS/2, or any number of weird setups. It's a large team with a lot of resources.
For now, our solution is probably going to be "roll OpenLDAP, keep it separate from the Unix LDAP (iPlanet on Solaris), and just maintain two separate directories..." (ugh... the Holy Grail of Single Sign On eludes us once again...)
IBM has a product called IBM Directory Integrator who's sole purpose in life is two syncronize two separate directories. You should check it out.
BTW, if you haven't figured it out by now, I work for IBM on Samba:-)
non-POSIX backends generally refer to backends that sit on storage devices or something like that. The idea is that Window's has a richer file-system model than POSIX (yeah, believe or not, some things are actually designed better in Windows).
Some non-POSIX storage devices (like for instance, IBM's Storage Tank) have more sophisticated features like snap-shotting that Windows also supports. The idea is to let those features be exposed to Windows clients instead of limiting the feature-set to those that are mappable to POSIX.
Actually, there is a CopyFile SMB. If it's there, Samba4 supports it. However, the burden really falls to the client here. It depends on how smart KDE would be in using the appropriate SMB's. Samba4's client libraries are much richer than Samba3's so the ability to do this would be exposed to them.
So, the short answer is yes, but it would require a much more sophisticated client than what you presently see today.
It would be nice if they actually fixed their LDAP code so that it would work with any directory server other than OpenLDAP.
It does. We routinely run it with IBM Directory Server.
and the buggy Samba implementation of LDAP as a storage mechanism for account information just doesn't work with anything other than OpenLDAP.
Were you linking against iPlanet LDAP libs or OpenLDAP libs? It's quite possible that you're linking against the OpenLDAP libs and that they're not getting along with iPlanet.
Samba only uses the standard LDAP calls. Other than the schema extensions (which unfortunately aren't in a standardized format) there's no LDAP-platform dependence.
It's bizzare, it's actually as if Samba is sending the XP client a buffer overflow while authenticating.
Why haven't you submitted this as a bug report at samba.org?
I spent weeks working with RHEL technical support,
Grab the latest from samba.org. The RHEL packages are sometimes quite old.
I'm sorry, but Samba is not ready for prime-time.
It's good that you made this decision for the world. Since noone's actually using Samba in production environments right now.
Look, Samba's used in a lot of enterprise environments. You're experience isn't the norm. You're environment also isn't the norm. Not many folks use iPlanet. Netscape's DS is also considered one of the lesser LDAP servers out there.
If this is a reproducable bug, and of the severity you describe, and is still present in the latest version of Samba, it's certainly be a high priority fix.
Keep in mind though, we don't do a lot of testing with things like iPlanet because we don't have access to copies of it. OpenLDAP and IDS get a lot of testing with Samba because people who work on Samba have ready access to it.
What's more, I don't see a single way in which any kind of LDAP failure could result in Samba sending an incorrect packet (with an incorrectly sized buffer) to a Windows client.
Samba3 is a mess. All the RPC code is hand-written, the SMB parsing logic is all over the place.
Samba4 automates the generate of most of the RPC code (the numbers change frequently, but it's something like 3,000 lines of IDL now replaces 100,000 lines of handcoded C).
Plus, Samba3 took the approach of just doing enough of the protocol so that it worked. You'd see a lot of mysterious += 8 where you'd just skip over chunks of the packet. In Samba4, every field is understand and accounted for.
Samba3 never could have been written as Samba4. Noone knew enough about SMB to understand that Samba4 was needed. This is really just Samba4 growing up.
The biggest user-visible change is going to be better Active Directory support. Active Directory support in Samba3 is painful. Very painful. If Samba4 does get it's own LDAP server, you may seem some extremely good interop in Samba4.
Nope. The greatest (from a business perspective) number of users of virtualization technology is in the enterprise market. That's the biggest reason people by systems like the z-Series--consolidation. The idea is that you consolidate a whole bunch of commody machines to one large system that's virtualized. You get the same network topology at the end of the day but a higher degree of reliability and a lower administration cost (hence lower TCO).
It's called software appliances. It's a terribly wonderful idea. It's definitely on my top 5 list of technologies that have the potential to revolutionize the industry.
If im correct, Vmware and VPC doesnt require the host operating system to be actually ported to the virtual system, whereas Xen does.
This isn't 100% correct. Both due require modifications to the underlying OS. The main difference is that VMWare and VPC does this dynamically. That is, it figures out at runtime where it needs to make changes and changes the binary.
The main difference is that para-virtualization requires more aggressive changes to the underlying OS. So much so, that it would be much less practical to do this sort of dynamic rewriting. That's not to say it's not possible or even that it hasn't been considered. There's just not really a compelling reason on a platform like Linux since you have the source code right there:-)
I started at a non-too well known state school and after the first two years my GPA was 4.0. I was very proud of this, until I told someone I worked with and they asked the obvious question. Why wasn't I at a better school?
If the school your at isn't stimulating you and pushing you to your limits, then by all means go somewhere else. If you're having a good time and learning a lot, then you're at the right place.
The work at a "more well known school" is going to be harder. Especially in CS. I don't know how well-known your thinking about, but if it's top 10, then the curiculum is likely to be much more theory intense. Since you probably don't have a strong background in theory (a generalization, I know), it's going to be even more work for you. In the better programs, abilities like formal theorem proven are just taken for granted in the upper division courses.
So far it probably sounds like you shouldn't transfer. However, yes, it does matter what school you are from. It doesn't matter if you're school is 34th vs. 35th per-say, but it certainly matters if it's top 10 or top 100. You will be competitive for jobs from a top 10 school that you probably won't be in just a top 100 school.
Sure, tons of experience is often a trumph card. I can attest to this. However, if you've got that ton of experience, all the more reason to get a deeper education that exposes you to things you won't learn on the job.
At this point too (you're junior year), it's too late to get that "ton of experience" if you don't have it. Everyone has an internship these days. It's not uncommon to have 4 or more either. I think "tons of experience" today constitutes somewhere on the order of 10 or more internships or a heck of a lot of Open Source experience (like large-project maintainer-level). Yes, this means internships back into high school. And yes, there's quite a few folks that have done that.
At the end of the day too, that the pace of the university your at will often match the types of job you can get. If you really like your university, you probably want the type of job graduates of your university would get. You really don't want to get a job you're not qualified to do. You're life will just be miserable.
I have this exact discussion quite often. The argument often boils down to this: putting a network file system in userspace would increase kernel stability and make it easier to write at the cost of performance. It would be very difficult to expose a stable user-level API for the necessary VM tweaks to put a network file system to it's performance limits.
Kind of. This is Microsoft marketing at it's finest. SMB is a protocol for sharing files. When the internet took off, Microsoft rebranded SMB as CIFS (or Common Internet File System). It's totally a marketing different. Both smbfs and cifsfs use SMB for file sharing (it's the only way to do file sharing).
The main differences in smbfs and cifsfs are 1) performance 2) unicode support 3) authentication.
cifsfs has much better performanced, negotiates unicode over the wire, and more important, uses a much stronger form of authentication (ntlmv2) than smbfs (lanman+ntlmv1). In fact, the authentication that smbfs is pretty much plain-text equivalent. Not to mention that smbfs does not support any sort of signing/sealing mechanism leaving your sessions wide open for hijacking.
At the end of the day, keep in mind though, that NFSv3 and below have an even worse design in terms of security. This is why you don't expose things like NFS and Windows file sharing over the internet. They just aren't normally very secure.
it has to be said CIFS is not mature yet (that's great seeing active developement there though)
Yes, CIFS has some bugs in it. However, so does SMBFS. In a lot of ways, SMBFS was never mature to begin with.
<i>how to you connect to legacy SMBFS servers which do not support CIFS</i>
The story basically is, SMBFS is there for that, however, if there is sufficient demand for legacy compatibility, I'm sure cifsfs will try to support it. It's not that difficult to do, just a matter of prioritization.
Open Source software only gets mature if people use it and submit bug reports when they encounter problems. If you want something to work better than smbfs and to not have gaping security holes the answer is to use cifsfs and file bug reports at https://bugzilla.samba.org.
Because linux does not fully support an implimentation any longer - an implimentation spec that was long ago abandoned by the people that made it,
No, the Samba community provided smbfs to solve a problem and now, we've done a rewrite and we have cifsfs. It's still a product of the Samba community.
The argument is more analogous to someone saying that FireFox 0.1 has does not support SSL and therefore is insecure. Well, hell, that's why there's FireFox 1.0. Upgrade and get over it.
Well, smbfs is deprecated for every day use. You'll see it in the kernel for a while as it supports older Win servers than CIFS. Basically, smbfs is if you need to have compatibility to really old servers. It's not suitable for a large-scale production environment though.
I mean, it's all kind of silly. smbfs sends plain-text equivalent passwords over the network. It's a giant open security whole. Screw some obsecure exploit. You're already open to the whole world by the very nature of the protocol.
I'll say this once, this is absolutely correct. We've known about this for a long time. SMBFS is deprecated. This is why CifsFS was written. CifsFS is a standard part of 2.6 and is available as patches for 2.4 from samba.org.
CifsFS is faster, works with newer versions of Windows better, and is much more secure. More importantly, SMBFS is not being maintained. Critical bug fixes get made but that's only because it's in the kernel. Please don't use it unless you have to.
Steve French is the author of CifsFS and has done a fantastic job with it.
SMB is entirely different from the basic protocols of the internet. Samba was not in the best legal situation to begin with, before MSFT came out with this licencing scheme. You can hardly equate SMB with TCP/IP.
Actually, SMB/NetBIOS was designed as an alternative to TCP/IP. SMB is much akin to TCP although quite a bit more functional. They are very much alike.
The licensing issues around the "Royality Free" CIFS license is that is expressly forbids using the information to implement a GPL-like licensed program. This is why Samba has the warning...
Hmmmm, who am I to argue here. Let me clarify a little:
User code runs in direct execution up to where it tries to make a system call or takes a page fault (etc.) and traps into privileged code.
Ok. User mode code isn't a problem.. privileged code is...
Privileged code is *dynamically* translated at runtime;
So then do you actually do emulation the first time around? The x86 instruction set is variable sized making it pretty impossible to accurately translate JIT. I'd imagine you'd have to do some form of emulation the first time around.
Since the only worrysome instructions should be iret, pushf, and popf, I can't see why you wouldn't use a translation table. It seems like that'd be a pretty big performance win.
This *is* what VirtualPC does. See the following presentation. See the "Guest OS Patching" section.
we don't have big tables that tell us exactly where all the instructions in each supported operating system need to be patched. That would be totally impractical.
Are you sure? I'm specifically referring to just the problem instructions (iret, pushf, and popf). I certainly have seen many problems with VMWare not being able to run non-supported OSes. I've got an MSDN subscription and have not been able to get *any* checked build to run. I'll look into submitting a bug report. I had just assumed it wasn't supported.
VMWare is a fine product. I was try to demonstrate the differences in a Full-Virtualization approach verses a Para-Virtualization. Thanks for clarifying.
BTW: I wasn't referring to the guest OS drivers, I was referring to the drivers required for install on the host OS. I assume these are necessary to intercept the traps for syscalls and page faults. An OS module is really modifying the host OS. I was trying to point out that VMWare requires host OS modification in order to work. Just pointing out that it's not as transparent as it appears to be:-)
Thanks again for the post.
VMWare is about virtualising a foreign OS. Since VMWare abstracts at the BIOS and hardware level it can run almost all OSes the CPU will support but it takes a large performance hit.
Hehe.. The VMWare marketing guys have gotten you pretty good. What your describing is something called full virtualization. It's what IBM does in PowerPC (with something like the OpenPower platform) and with hardware support can be pretty darn fast.
The IA-32 architecture is not capable of full virtualization. If you don't believe me, just read any of the dozens of papers written on the topic. Memory poses a problem (albiet one that's overcomable) but the thing that makes it impossible is the behavior of three instructions.
Virtualization's really a simple concept. You run an OS at a lower priviledge than it expects and the priviledged instructions will throw exceptions that can be caught and emulated. Certain instructions on IA-32 silently fail when executed outside of ring 0 making it impossible to emulate those instructions.
What tools like VMWare do is run through the executable and change those instructions to illegal instructions or do dynamic rewriting of the executable. That's right, they have to dynamically rewrite the executable. Have you ever wondered why VMWare asks you what OS it will be running? Because it has a big set of tables of where instructions need to be rewritten. Have you ever tried to run a checked build of Windows in VMWare or better yet a newer version of Windows that just isn't supported?
It fails miserably. The difference between VMWare and Xen is that Xen accepts the difficulties and then decides that if we're already going to change the OS, let's just make a few more changes to improve performance.
Adding VMWare-style virtualization support to Xen wouldn't be that difficult if you have the tables and such that VMWare had. Remember too, VMWare requires OS-drivers to be installed.. there's a reason for that.
I can't tell you how many times I mistype a common command.. like `la' instead of `ls'. Having '.' in your $PATH would allow a malicous user to take advantage of that.
I guess you invented all your crypto and wrote your own libc?
No, I've used libraries that I have the legal right to use provided I use the publicly documented interfaces and/or abide by the copyright restrictions.
Reading a reference implementation is MANDATORY for doing most of the things I do.
Reference implementations are often in the public domain. They always are licensed in such a way that you can use the code in your own application.
(yeah , like reading pySerial and redoing it in C is copyright violation).
Actually, it can be. If you took pySerial and rewrote it in C, then your creation is a derivative work. If it's a derivative work, it's a copyright violation.
What all this gave me in college is a skill at understanding code I never wrote and debugging it.
No, it simply taught you how to steal. You can learn to understand code by participating in Open Source projects or by working on programming project teams. Pair programming seems to be all the rage these days in Universities so I contend that there are plenty of opportunities to pick up these skills without resorting to stealing.
Slashdot Mirror
Well, you see, that's the problem... Management refuses to let me implement a solution that's not supported, and as soon as I go and compile Samba custom, I lose the ability to call Redhat for support.
:-) This is not why. The problem is LDAP interoperability. OpenLDAP strives for compliance to the LDAP RFCs. Samba strives for interop with Windows. Microsoft's LDAP server does not obey the LDAP RFCs in a number of important ways. It's all pretty obscure, but suffice to say that without implementing our own LDAP server, we could never get great Active Directory interop.
:-) We've taken bug reports that require mainframes, metaframe client, OS/2, or any number of weird setups. It's a large team with a lot of resources.
:-)
Yeah, I figured this. This is very common. Are you using the latest RHEL package available though? RHEL3 ships with a version poor version of Samba (like 3.0.0rcXXX or something). I've had tons of problems with it. You can get pretty much the newest version from RedHat though.
Even the Samba team has realized that OpenLDAP sucks and has started writing their own LDAP implementation for Samba 4 (look in the roadmap, you'll see it's in there, but not yet started or written yet).
Also, did you have to compile Samba with IBM's LDAP libraries to make it work properly?
Nope. It should work out of the box.
Because I know they'd probably throw it back in my face and say it's unreproduceable since who wants to install Iplanet Directory Server and set up a whole PDC + Windows XP client just to reproduce the bug?
Nope, we don't do that
For now, our solution is probably going to be "roll OpenLDAP, keep it separate from the Unix LDAP (iPlanet on Solaris), and just maintain two separate directories..." (ugh... the Holy Grail of Single Sign On eludes us once again...)
IBM has a product called IBM Directory Integrator who's sole purpose in life is two syncronize two separate directories. You should check it out.
BTW, if you haven't figured it out by now, I work for IBM on Samba
non-POSIX backends generally refer to backends that sit on storage devices or something like that. The idea is that Window's has a richer file-system model than POSIX (yeah, believe or not, some things are actually designed better in Windows).
Some non-POSIX storage devices (like for instance, IBM's Storage Tank) have more sophisticated features like snap-shotting that Windows also supports. The idea is to let those features be exposed to Windows clients instead of limiting the feature-set to those that are mappable to POSIX.
Actually, there is a CopyFile SMB. If it's there, Samba4 supports it. However, the burden really falls to the client here. It depends on how smart KDE would be in using the appropriate SMB's. Samba4's client libraries are much richer than Samba3's so the ability to do this would be exposed to them.
So, the short answer is yes, but it would require a much more sophisticated client than what you presently see today.
It would be nice if they actually fixed their LDAP code so that it would work with any directory server other than OpenLDAP.
It does. We routinely run it with IBM Directory Server.
and the buggy Samba implementation of LDAP as a storage mechanism for account information just doesn't work with anything other than OpenLDAP.
Were you linking against iPlanet LDAP libs or OpenLDAP libs? It's quite possible that you're linking against the OpenLDAP libs and that they're not getting along with iPlanet.
Samba only uses the standard LDAP calls. Other than the schema extensions (which unfortunately aren't in a standardized format) there's no LDAP-platform dependence.
It's bizzare, it's actually as if Samba is sending the XP client a buffer overflow while authenticating.
Why haven't you submitted this as a bug report at samba.org?
I spent weeks working with RHEL technical support,
Grab the latest from samba.org. The RHEL packages are sometimes quite old.
I'm sorry, but Samba is not ready for prime-time.
It's good that you made this decision for the world. Since noone's actually using Samba in production environments right now.
Look, Samba's used in a lot of enterprise environments. You're experience isn't the norm. You're environment also isn't the norm. Not many folks use iPlanet. Netscape's DS is also considered one of the lesser LDAP servers out there.
If this is a reproducable bug, and of the severity you describe, and is still present in the latest version of Samba, it's certainly be a high priority fix.
Keep in mind though, we don't do a lot of testing with things like iPlanet because we don't have access to copies of it. OpenLDAP and IDS get a lot of testing with Samba because people who work on Samba have ready access to it.
What's more, I don't see a single way in which any kind of LDAP failure could result in Samba sending an incorrect packet (with an incorrectly sized buffer) to a Windows client.
Bugzilla is your friend.
Samba3 is a mess. All the RPC code is hand-written, the SMB parsing logic is all over the place.
Samba4 automates the generate of most of the RPC code (the numbers change frequently, but it's something like 3,000 lines of IDL now replaces 100,000 lines of handcoded C).
Plus, Samba3 took the approach of just doing enough of the protocol so that it worked. You'd see a lot of mysterious += 8 where you'd just skip over chunks of the packet. In Samba4, every field is understand and accounted for.
Samba3 never could have been written as Samba4. Noone knew enough about SMB to understand that Samba4 was needed. This is really just Samba4 growing up.
The biggest user-visible change is going to be better Active Directory support. Active Directory support in Samba3 is painful. Very painful. If Samba4 does get it's own LDAP server, you may seem some extremely good interop in Samba4.
Dude, what do you think OpenPower is? Open. The new p-Series machines are all about openness. The OpenPower 720's actually only run Linux.
Nope. The greatest (from a business perspective) number of users of virtualization technology is in the enterprise market. That's the biggest reason people by systems like the z-Series--consolidation. The idea is that you consolidate a whole bunch of commody machines to one large system that's virtualized. You get the same network topology at the end of the day but a higher degree of reliability and a lower administration cost (hence lower TCO).
It's an amazingly powerful bussiness case.
It's called software appliances. It's a terribly wonderful idea. It's definitely on my top 5 list of technologies that have the potential to revolutionize the industry.
If im correct, Vmware and VPC doesnt require the host operating system to be actually ported to the virtual system, whereas Xen does.
:-)
This isn't 100% correct. Both due require modifications to the underlying OS. The main difference is that VMWare and VPC does this dynamically. That is, it figures out at runtime where it needs to make changes and changes the binary.
The main difference is that para-virtualization requires more aggressive changes to the underlying OS. So much so, that it would be much less practical to do this sort of dynamic rewriting. That's not to say it's not possible or even that it hasn't been considered. There's just not really a compelling reason on a platform like Linux since you have the source code right there
Is it high? A 4.0 perhaps?
I started at a non-too well known state school and after the first two years my GPA was 4.0. I was very proud of this, until I told someone I worked with and they asked the obvious question. Why wasn't I at a better school?
If the school your at isn't stimulating you and pushing you to your limits, then by all means go somewhere else. If you're having a good time and learning a lot, then you're at the right place.
The work at a "more well known school" is going to be harder. Especially in CS. I don't know how well-known your thinking about, but if it's top 10, then the curiculum is likely to be much more theory intense. Since you probably don't have a strong background in theory (a generalization, I know), it's going to be even more work for you. In the better programs, abilities like formal theorem proven are just taken for granted in the upper division courses.
So far it probably sounds like you shouldn't transfer. However, yes, it does matter what school you are from. It doesn't matter if you're school is 34th vs. 35th per-say, but it certainly matters if it's top 10 or top 100. You will be competitive for jobs from a top 10 school that you probably won't be in just a top 100 school.
Sure, tons of experience is often a trumph card. I can attest to this. However, if you've got that ton of experience, all the more reason to get a deeper education that exposes you to things you won't learn on the job.
At this point too (you're junior year), it's too late to get that "ton of experience" if you don't have it. Everyone has an internship these days. It's not uncommon to have 4 or more either. I think "tons of experience" today constitutes somewhere on the order of 10 or more internships or a heck of a lot of Open Source experience (like large-project maintainer-level). Yes, this means internships back into high school. And yes, there's quite a few folks that have done that.
At the end of the day too, that the pace of the university your at will often match the types of job you can get. If you really like your university, you probably want the type of job graduates of your university would get. You really don't want to get a job you're not qualified to do. You're life will just be miserable.
I had constructed a reply, but then found this link that said everything I was going to say:
Power
You're actually quite mistaken. The POWER family includes PowerPC along with a bunch of other processors.
This is the first POWER chip to be produced in volume (I'm not counting workstation / server chips as volume).
Except for the fact that it's widely known that the highest volume PowerPC chip is the processor inside the Nintendo GameCube.
I have this exact discussion quite often. The argument often boils down to this: putting a network file system in userspace would increase kernel stability and make it easier to write at the cost of performance. It would be very difficult to expose a stable user-level API for the necessary VM tweaks to put a network file system to it's performance limits.
The FreeBSD smbfs was forked off of the Linux smbfs a long time ago. You'd have to analysis it separately to determine if it was also vunerable.
Kind of. This is Microsoft marketing at it's finest. SMB is a protocol for sharing files. When the internet took off, Microsoft rebranded SMB as CIFS (or Common Internet File System). It's totally a marketing different. Both smbfs and cifsfs use SMB for file sharing (it's the only way to do file sharing). The main differences in smbfs and cifsfs are 1) performance 2) unicode support 3) authentication. cifsfs has much better performanced, negotiates unicode over the wire, and more important, uses a much stronger form of authentication (ntlmv2) than smbfs (lanman+ntlmv1). In fact, the authentication that smbfs is pretty much plain-text equivalent. Not to mention that smbfs does not support any sort of signing/sealing mechanism leaving your sessions wide open for hijacking. At the end of the day, keep in mind though, that NFSv3 and below have an even worse design in terms of security. This is why you don't expose things like NFS and Windows file sharing over the internet. They just aren't normally very secure.
it has to be said CIFS is not mature yet (that's great seeing active developement there though)
Yes, CIFS has some bugs in it. However, so does SMBFS. In a lot of ways, SMBFS was never mature to begin with.
<i>how to you connect to legacy SMBFS servers which do not support CIFS</i>
The story basically is, SMBFS is there for that, however, if there is sufficient demand for legacy compatibility, I'm sure cifsfs will try to support it. It's not that difficult to do, just a matter of prioritization.
Open Source software only gets mature if people use it and submit bug reports when they encounter problems. If you want something to work better than smbfs and to not have gaping security holes the answer is to use cifsfs and file bug reports at https://bugzilla.samba.org.
Because linux does not fully support an implimentation any longer - an implimentation spec that was long ago abandoned by the people that made it, No, the Samba community provided smbfs to solve a problem and now, we've done a rewrite and we have cifsfs. It's still a product of the Samba community. The argument is more analogous to someone saying that FireFox 0.1 has does not support SSL and therefore is insecure. Well, hell, that's why there's FireFox 1.0. Upgrade and get over it.
Well, smbfs is deprecated for every day use. You'll see it in the kernel for a while as it supports older Win servers than CIFS. Basically, smbfs is if you need to have compatibility to really old servers. It's not suitable for a large-scale production environment though. I mean, it's all kind of silly. smbfs sends plain-text equivalent passwords over the network. It's a giant open security whole. Screw some obsecure exploit. You're already open to the whole world by the very nature of the protocol.
Yeah, unfortunately, not many folks work on CifsFS. You're best bet is to send it to linux-cifs-client@lists.samba.org.
I'll say this once, this is absolutely correct. We've known about this for a long time. SMBFS is deprecated. This is why CifsFS was written. CifsFS is a standard part of 2.6 and is available as patches for 2.4 from samba.org. CifsFS is faster, works with newer versions of Windows better, and is much more secure. More importantly, SMBFS is not being maintained. Critical bug fixes get made but that's only because it's in the kernel. Please don't use it unless you have to. Steve French is the author of CifsFS and has done a fantastic job with it.
SMB is entirely different from the basic protocols of the internet. Samba was not in the best legal situation to begin with, before MSFT came out with this licencing scheme. You can hardly equate SMB with TCP/IP. Actually, SMB/NetBIOS was designed as an alternative to TCP/IP. SMB is much akin to TCP although quite a bit more functional. They are very much alike. The licensing issues around the "Royality Free" CIFS license is that is expressly forbids using the information to implement a GPL-like licensed program. This is why Samba has the warning...
Hmmmm, who am I to argue here. Let me clarify a little: User code runs in direct execution up to where it tries to make a system call or takes a page fault (etc.) and traps into privileged code. Ok. User mode code isn't a problem.. privileged code is... Privileged code is *dynamically* translated at runtime; So then do you actually do emulation the first time around? The x86 instruction set is variable sized making it pretty impossible to accurately translate JIT. I'd imagine you'd have to do some form of emulation the first time around. Since the only worrysome instructions should be iret, pushf, and popf, I can't see why you wouldn't use a translation table. It seems like that'd be a pretty big performance win. This *is* what VirtualPC does. See the following presentation. See the "Guest OS Patching" section. we don't have big tables that tell us exactly where all the instructions in each supported operating system need to be patched. That would be totally impractical. Are you sure? I'm specifically referring to just the problem instructions (iret, pushf, and popf). I certainly have seen many problems with VMWare not being able to run non-supported OSes. I've got an MSDN subscription and have not been able to get *any* checked build to run. I'll look into submitting a bug report. I had just assumed it wasn't supported. VMWare is a fine product. I was try to demonstrate the differences in a Full-Virtualization approach verses a Para-Virtualization. Thanks for clarifying. BTW: I wasn't referring to the guest OS drivers, I was referring to the drivers required for install on the host OS. I assume these are necessary to intercept the traps for syscalls and page faults. An OS module is really modifying the host OS. I was trying to point out that VMWare requires host OS modification in order to work. Just pointing out that it's not as transparent as it appears to be :-)
Thanks again for the post.
VMWare is about virtualising a foreign OS. Since VMWare abstracts at the BIOS and hardware level it can run almost all OSes the CPU will support but it takes a large performance hit. Hehe.. The VMWare marketing guys have gotten you pretty good. What your describing is something called full virtualization. It's what IBM does in PowerPC (with something like the OpenPower platform) and with hardware support can be pretty darn fast. The IA-32 architecture is not capable of full virtualization. If you don't believe me, just read any of the dozens of papers written on the topic. Memory poses a problem (albiet one that's overcomable) but the thing that makes it impossible is the behavior of three instructions. Virtualization's really a simple concept. You run an OS at a lower priviledge than it expects and the priviledged instructions will throw exceptions that can be caught and emulated. Certain instructions on IA-32 silently fail when executed outside of ring 0 making it impossible to emulate those instructions. What tools like VMWare do is run through the executable and change those instructions to illegal instructions or do dynamic rewriting of the executable. That's right, they have to dynamically rewrite the executable. Have you ever wondered why VMWare asks you what OS it will be running? Because it has a big set of tables of where instructions need to be rewritten. Have you ever tried to run a checked build of Windows in VMWare or better yet a newer version of Windows that just isn't supported? It fails miserably. The difference between VMWare and Xen is that Xen accepts the difficulties and then decides that if we're already going to change the OS, let's just make a few more changes to improve performance. Adding VMWare-style virtualization support to Xen wouldn't be that difficult if you have the tables and such that VMWare had. Remember too, VMWare requires OS-drivers to be installed.. there's a reason for that.
I can't tell you how many times I mistype a common command.. like `la' instead of `ls'. Having '.' in your $PATH would allow a malicous user to take advantage of that.
I guess you invented all your crypto and wrote your own libc? No, I've used libraries that I have the legal right to use provided I use the publicly documented interfaces and/or abide by the copyright restrictions. Reading a reference implementation is MANDATORY for doing most of the things I do. Reference implementations are often in the public domain. They always are licensed in such a way that you can use the code in your own application. (yeah , like reading pySerial and redoing it in C is copyright violation). Actually, it can be. If you took pySerial and rewrote it in C, then your creation is a derivative work. If it's a derivative work, it's a copyright violation. What all this gave me in college is a skill at understanding code I never wrote and debugging it. No, it simply taught you how to steal. You can learn to understand code by participating in Open Source projects or by working on programming project teams. Pair programming seems to be all the rage these days in Universities so I contend that there are plenty of opportunities to pick up these skills without resorting to stealing.