Actually as Sun is one of the biggest nfsv4 fans it's more likely you'll see nfsv4 acls in Solaris than Linux (in fact I think it already has them in Solaris 10). Now I (or someone else) needs to write the VFS module to plug them in.
You're still asking for your pony without telling anyone where it will live.
Samba maps Windows semantics to POSIX. There are some semantics you simply can't map onto POSIX - the Windows access time / create time semantics for example, so we simply can't provide these. Some POSIX semantics are flexible enough we can layer Windows on top (locking for example).
Until the kernel gets NFSv4 ACLs that mean NT style ACLs can be understood there anything Samba does on top of this will not map into anything meaningful.
There are inherent limitations in POSIX that mean we can't do this - yet. Luckily for us the UNIX/Linux standards are being extended so we can revisit it when they do.
I'm glad you asked that:-). It's not currently possible in CIFS - you need a secure network.
But Steve French (CIFSFS Linux client) and I are looking at ways to add krb5/gss encryption to Linux/MacOSX/HPUX CIFS clients when talking to Samba servers using the UNIX extensions.
Won't work with Windows clients unless Microsoft decides to implement what we design (and publish the protocol in an rfc of course) but then again you should be using Linux or Mac clients anyway to get the extra cool features:-):-).
It's me you're complaining about here, as I wrote (and maintain) the POSIX ACL code in Samba.
I understand your problem, but you've got to realize there's nowhere on a UNIX filesystem to store that meta-data and have the kernel understand it.
Sure, we can push the NT ACLs into an EA, but nothing in the kernel will look at that EA or even be able to make sense of the SIDs stored within it.
We can do the interpretation inside Samba but this doesn't prevent other POSIX processes from completely ignoring whatever ACLs you thought you'd securely set on that file. NetApp can do this as they have their own kernel (based on FreeBSD originally) which they've hacked to understand these ACLs. Samba isn't a kernel, and so can't do this:-).
NFSv4 ACLs, whilst having their own problems, are much closer to what we need to store full NT ACLs. Unfortunately they (a) break POSIX, (b) aren't yet finished on the most popular platorm (Linux) and (c) have no userspace API standard for getting to them.
This is one of the reasons my world sucks (Microsoft DFS is another at the moment:-):-).
Your complaint is like a child screaming "I want a pony, I want a pony...". We *all* want a pony. Where is it going to live.....:-).
Well obviously I disagree:-). I did what I thought was right, I didn't want to support a company using a legal "hack" to try and get around their license obligations. The great thing about the GPL is that we're all in it together - that means you too if you want to work with it. The only people who continually complain about the GPL are usually those that want to use the software without obeying the licensing terms associated with it.
Proprietary software companies call those people "pirates" (*) and there are laws against that kind of behaviour. The GPL uses the same law to ensure freedom for the software.
Jeremy.
(*) I dislike the term, but I disagree with rms who claims that people should be able to copy proprietary software freely. If you don't respect other people's licenses, even if you think they're unethical, how can you expect them to respect yours ?
Note that Ron in the interview doesn't say *when* the Microsoft request that :
"Their desire to do some things around IP [intellectual property] came up"
happened. I believe that this request came at the end of the negotiations, not at the start. I can't prove that, but but the timing of things makes sense from what happened.
"Their desire to do some things around IP [intellectual property] came up as one of the things they wanted to talk about."
In addition Microsoft previously approached Red Hat with a request for exactly the same deal (Red Hat refused).
I don't have 100% documented proof of my statement, which is why I started the sentance with "My guess is", but I still stand by it as my understanding of what happened.
"As you will notice EVERY BIT of information and the license to utilize the CIFS technologies is fully available for free from Microsoft, no reverse engineering required."
This is completely untrue, as I'm sure you know. I could enumerate all the still-unknown parts of CIFS, but I don't normally engage with trolls unless it's to point out when they are spreading lies, which is what I'm doing here.
Not answering your question, but taking the opportunity to talk to an InfoWorld editor....:-).
As someone who makes their living creating interoperable software with Microsoft Windows, I have to say that even with the appointment of Bill Hilf (who is a very nice guy personally) and the Port25 crowd in Microsoft's interoperability lab I haven't seen much of a difference in Microsoft's attitude to OSS and interoperability. That is, they *hate* it:-). Currently they're on a big publicity push to explain to customers (who usually don't understand much of the technical details) how interested they are in interoperability with OSS software, but it's a really hard problem etc. etc. The problem is it's not actually a hard problem, they just need to document the proprietary way they do things. There are few (if any) proprietary protocols on the OSS/Linux side of things.
Interoperability with Microsoft is actually quite easy from their side, as they're the ones who create the difficulties. If Microsoft wanted to promote interop they'd fully document the specs that the EU is asking for in the anti-trust case. A sea change from Microsoft will come if you see them actually comply with the EU judgement. Until they do they can talk up interop until they're blue in the face but they're not actually doing anything about it.
I've sat down with Microsoft execs and tried to explain they need to see GPL software as an opportunity, not a threat. They need to try and work out how to make money with it. IBM has figured this out (so have Red Hat and others). The problem is Microsoft make too much money on their current business model (a monopoly, charging monopoly rent) in order for them to easily change.
It's a problem for them, in many ways I do sympathise....
Actually I did make a Steve Ballmer chair joke. That was the bonus question on the "Sample" round where I'm teaching them how to play the game. The question was "Why does Scott McNealy look so relaxed in this picture [with Ballmer]" ? Answer : Because Ballmer is sitting on the chair and it doesn't come easily to hand as a weapon:-). But then I laugh at my own jokes (I know I shouldn't:-).
You don't understand. No one is accusing Microsoft of not documenting their API's for interoperability, it's the *network protocols* that these API's map into that Microsoft willfully refuses to document.
Let me give you an example. Microsoft might have an (hypothetical) API that from Win32 looks like :
Documentation says it returns a Win32 error if the username, domain or password is bad and an NT_STATUS_OK if all are correct.
There - complete documentation on how to log onto a domain.....
Except - if you're implementing a server on a non-Windows platform that has to respond to this API there are some questions this doc doesn't begin to answer.
1). How does the client find the domain controller ? TCP ? UDP ? NetBEUI ? What port does it use ? What does the query look like ?
2). How is the username and password encoded on the wire ? How are the single sign on credentials returned to the client ? What protocol is used ? What wire encoding ?
See - you can document API's all you want and yet reveal *nothing* about interoperability.
Microsoft keeps trying to confuse APIs and Network protocols (and also source code, but that's another story).
These are different things. You can document one and not another. If I were to guess (not having seen any Microsoft docs they're offering to the EU) I'd guess the docs are very much like the example above. Completely and utterly useless for network interoperability.
Just a quick fyi. The winbindd cache is persistent, so it will always map the same way on subseqent lookups. The winbindd uid/gid cache can also be remoted onto an LDAP server, making the cache common between multiple instances of winbindd on different machines. So it's not as bad as you paint it and is used in some very large organisations as their main mapping mechanism between Windows and UNIX.
The inner forward slashes are doubled to make it clear it's not an absolute pathname on the local filesystem, to show the first component is "special" and designates a remote machine name.
It's actually a syntax that was first created for RFS I believe, but has been adopted by many other remote filesystems for UNIX, as well as http and other protocols.
Then type smbclient//i//love//forward_slashes. It's worked with that syntax for.... oh about 10 years, but then again this *is* slashdot so I can't expect you to know what you're talking about...:-).
"If someone in the OSS community runs into a technical interoperability problem with Microsoft products, I want to know about it."
Thanks Bill. So how about the IDL files for all the undocumented Microsoft RPC services your clients depend on for login as well as the "standards" based parts of login ?
We're still waiting.... no, we won't go away:-).
Knowing about it doesn't help if you never *do* anything about it.
Cheers,
Jeremy Allison, Samba Team.
Re:Make a deal with the devil...
on
SGI Faces Bankruptcy
·
· Score: 5, Insightful
Completely untrue. I was at SGI at the time. The grpahics workstation business wasn't great, but not collapsed.
The original poster was completely correct, the Microsoft deal burned $300 million of much needed cash.
The Farenheight debacle was another aspect of it. *DONT* deal with Microsoft. Just don't. Ever. No matter how attractive it looks on the surface.
But greed keeps people thinking "but it'll be different for *me*. They won't screw over *me*. I'm different....). Wait until Microsoft pulls the plug on the Microsoft/NetApp agreements for more of the same.
Thanks Bruce. This is *exactly* what happened. I'm hoping that when tridge's code finally becomes available people will be able to see the truth of the matter.
To those who don't know, Roger Binns is responsible for Samba having the fastest share-mode lock code possible, as he goaded me into doing it by claiming it required a lock daemon. I was determined to prove him wrong...:-).
Roger is also responsible for VisionFS (the *old*, good SCO's decent SMB file/print server).
Plus he holds a mean barbequeue:-). Even though his taste in toenail polish is *deplorable*:-).
I'm only going to say one thing here, and then leave it at that. As has been pointed out before, Luke has a very selective memory about his involvement with Samba.
Yes he made substantial contributions, for which we were very grateful, but in the end the difficulties in working together outweighed the benfits.
I'm not going to say any more - those who are interested can read the relevent email archives.
Slashdot Mirror
Actually as Sun is one of the
biggest nfsv4 fans it's more
likely you'll see nfsv4 acls
in Solaris than Linux (in fact
I think it already has them in
Solaris 10). Now I (or someone
else) needs to write the VFS
module to plug them in.
IBM has already done this for
Samba in AIX.
Jeremy
You're still asking for your pony without
telling anyone where it will live.
Samba maps Windows semantics to POSIX.
There are some semantics you simply
can't map onto POSIX - the Windows
access time / create time semantics
for example, so we simply can't
provide these. Some POSIX semantics
are flexible enough we can layer
Windows on top (locking for example).
Until the kernel gets NFSv4 ACLs
that mean NT style ACLs can be understood
there anything Samba does on top of
this will not map into anything meaningful.
There are inherent limitations in POSIX
that mean we can't do this - yet. Luckily
for us the UNIX/Linux standards are being
extended so we can revisit it when they
do.
Jeremy.
I'm glad you asked that :-). It's not currently
:-) :-).
possible in CIFS - you need a secure network.
But Steve French (CIFSFS Linux client) and I
are looking at ways to add krb5/gss encryption
to Linux/MacOSX/HPUX CIFS clients when talking
to Samba servers using the UNIX extensions.
Won't work with Windows clients unless Microsoft
decides to implement what we design (and publish
the protocol in an rfc of course) but then again
you should be using Linux or Mac clients anyway to
get the extra cool features
Come to the SambaXP conference to hear more....
http://sambaxp.org/
Jeremy.
It's me you're complaining about here, as I wrote (and maintain)
:-).
:-) :-).
:-).
the POSIX ACL code in Samba.
I understand your problem, but you've got to realize there's
nowhere on a UNIX filesystem to store that meta-data and have
the kernel understand it.
Sure, we can push the NT ACLs into an EA, but nothing in
the kernel will look at that EA or even be able to make sense
of the SIDs stored within it.
We can do the interpretation inside Samba but this doesn't
prevent other POSIX processes from completely ignoring
whatever ACLs you thought you'd securely set on that file.
NetApp can do this as they have their own kernel (based
on FreeBSD originally) which they've hacked to understand
these ACLs. Samba isn't a kernel, and so can't do this
NFSv4 ACLs, whilst having their own problems, are much closer
to what we need to store full NT ACLs. Unfortunately they (a)
break POSIX, (b) aren't yet finished on the most popular
platorm (Linux) and (c) have no userspace API standard for
getting to them.
This is one of the reasons my world sucks (Microsoft DFS is
another at the moment
Your complaint is like a child screaming "I want a pony,
I want a pony...". We *all* want a pony. Where is it going
to live.....
Jeremy.
Well obviously I disagree :-). I did what I thought was right, I didn't want to support a company using a legal "hack" to try and get around their license obligations. The great thing about the GPL is that we're all in it together - that means you too if you want to work with it. The only people who continually complain about the GPL are usually those that want to use the software without obeying the licensing terms associated with it.
Proprietary software companies call those people "pirates" (*) and there are laws against that kind of behaviour. The GPL uses the same law to ensure freedom for the software.
Jeremy.
(*) I dislike the term, but I disagree with rms who claims that people should be able to copy proprietary software freely. If you don't respect other people's licenses, even if you think they're unethical, how can you expect them to respect yours ?
Note that Ron in the interview doesn't say *when* the Microsoft
request that :
"Their desire to do some things around
IP [intellectual property] came up"
happened. I believe that this request came at the end of
the negotiations, not at the start. I can't prove that,
but but the timing of things makes sense from what happened.
Jeremy.
It is a guess, but it's a very good guess. From an interview with Ron Hovsepian
m mand=viewArticleBasic&articleId=9005462&pageNumber =2
http://www.computerworld.com/action/article.do?co
"Their desire to do some things around IP [intellectual property] came up as
one of the things they wanted to talk about."
In addition Microsoft previously approached Red Hat with
a request for exactly the same deal (Red Hat refused).
I don't have 100% documented proof of my statement, which is
why I started the sentance with "My guess is", but I still
stand by it as my understanding of what happened.
Jeremy.
Yeah well I work for Novell. So what do you have to say about that ?
I can say this statement was agreed upon unanimously by the Team.
Jeremy Allison,
Samba Team.
No, you can execute directly out of the alternate data stream so long as you end the stream name in .exe....
y &id=53
:-).
See here:
http://www.infosecwriters.com/texts.php?op=displa
for details. It shows a process listing with myfile.txt listed as a running process.
Scary stuff
Jeremy.
"As you will notice EVERY BIT of information and the license to utilize the CIFS technologies is fully available for free from Microsoft, no reverse engineering required."
This is completely untrue, as I'm sure you know. I could enumerate all the still-unknown parts of CIFS, but I don't normally engage with trolls unless it's to point out when they are spreading lies, which is what I'm doing here.
Jeremy Allison,
Samba Team.
Not answering your question, but taking the opportunity to talk to an InfoWorld editor.... :-).
:-). Currently they're on a big publicity push to explain to customers (who usually don't understand much of the technical details) how interested they are in interoperability with OSS software, but it's a really hard problem etc. etc. The problem is it's not actually a hard problem, they just need to document the proprietary way they do things. There are few (if any) proprietary protocols on the OSS/Linux side of things.
As someone who makes their living creating interoperable software with Microsoft Windows, I have to say that even with the appointment of Bill Hilf (who is a very nice guy personally) and the Port25 crowd in Microsoft's interoperability lab I haven't seen much of a difference in Microsoft's attitude to OSS and interoperability. That is, they *hate* it
Interoperability with Microsoft is actually quite easy from their side, as they're the ones who create the difficulties. If Microsoft wanted to promote interop they'd fully document the specs that the EU is asking for in the anti-trust case. A sea change from Microsoft will come if you see them actually comply with the EU judgement. Until they do they can talk up interop until they're blue in the face but they're not actually doing anything about it.
I've sat down with Microsoft execs and tried to explain they need to see GPL software as an opportunity, not a threat. They need to try and work out how to make money with it. IBM has figured this out (so have Red Hat and others). The problem is Microsoft make too much money on their current business model (a monopoly, charging monopoly rent) in order for them to easily change.
It's a problem for them, in many ways I do sympathise....
Jeremy Allison,
Samba Team.
Actually I did make a Steve Ballmer chair joke. That was the bonus question on the "Sample" round where I'm teaching them how to play the game. The question was "Why does Scott McNealy look so relaxed in this picture [with Ballmer]" ? :-). :-).
Answer : Because Ballmer is sitting on the chair and it doesn't come easily to hand as a weapon
But then I laugh at my own jokes (I know I shouldn't
Jeremy.
You don't understand. No one is accusing Microsoft of not documenting their API's for interoperability, it's the *network protocols* that these API's map into that Microsoft willfully refuses to document.
Let me give you an example. Microsoft might have an (hypothetical) API that from Win32 looks like :
DWORD LogonUserToDomain(const char *domain, const char *username, const char *password)
Documentation says it returns a Win32 error if the username, domain or password is bad and an NT_STATUS_OK if all are correct.
There - complete documentation on how to log onto a domain.....
Except - if you're implementing a server on a non-Windows platform that has to respond to this API there are some questions this doc doesn't begin to answer.
1). How does the client find the domain controller ? TCP ? UDP ? NetBEUI ? What port does it use ? What does the query look like ?
2). How is the username and password encoded on the wire ? How are the single sign on credentials returned to the client ? What protocol is used ? What wire encoding ?
See - you can document API's all you want and yet reveal *nothing* about interoperability.
Microsoft keeps trying to confuse APIs and Network protocols (and also source code, but that's another story).
These are different things. You can document one and not another. If I were to guess (not having seen any Microsoft docs they're offering to the EU) I'd guess the docs are very much like the example above. Completely and utterly useless for network interoperability.
Jeremy Allison,
Samba Team.
Doh ! oh I see, you meant the "inner" forward slashes, not the first one.
:-).
That's because I typed it wrong
Sorry,
Jeremy.
Just a quick fyi. The winbindd cache is persistent, so it will always map the same way on subseqent lookups. The winbindd uid/gid cache can also be remoted onto an LDAP server, making the cache common between multiple instances of winbindd on different machines. So it's not as bad as you paint it and is used in some very large organisations as their main mapping mechanism between Windows and UNIX.
Jeremy.
The inner forward slashes are doubled to make it clear it's not an absolute pathname on the local filesystem, to show the first component is "special" and designates a remote machine name.
It's actually a syntax that was first created for RFS I believe, but has been adopted by many other remote filesystems for UNIX, as well as http and other protocols.
Jeremy.
Then type smbclient //i//love//forward_slashes. :-).
It's worked with that syntax for.... oh about 10 years, but then again this *is* slashdot so I can't expect you to know what you're talking about...
Jeremy.
"If someone in the OSS community runs into a technical interoperability problem with Microsoft products, I want to know about it."
:-).
Thanks Bill. So how about the IDL files for all the undocumented Microsoft RPC services your clients depend on for login as well as the "standards" based parts of login ?
We're still waiting.... no, we won't go away
Knowing about it doesn't help if you never *do* anything about it.
Cheers,
Jeremy Allison,
Samba Team.
Completely untrue. I was at SGI at the time. The grpahics workstation business wasn't great, but not collapsed.
The original poster was completely correct, the Microsoft deal burned $300 million of much needed cash.
The Farenheight debacle was another aspect of it. *DONT* deal with Microsoft. Just don't. Ever. No matter how attractive it looks on the surface.
But greed keeps people thinking "but it'll be different for *me*. They won't screw over *me*. I'm different....). Wait until Microsoft pulls the plug on the Microsoft/NetApp agreements for more of the same.
Jeremy.
Then you would be wrong. He attempted to work with them for a *long* time before they did this.
They wanted to *own* the kernel meta-data, not the developers. I personally disagree with that.
Jeremy.
Thanks Bruce. This is *exactly* what happened. I'm hoping that when tridge's code finally becomes available people will be able to see the truth of the matter.
Jeremy.
You are wrong. tridge does not use bk as part of his OSDL work (which is entirely on Samba4).
Jeremy Allison,
Samba Team.
Indeed. I've been staying out of this as I know too much about what really happened to comment publicly.
But one thing I will say is that tridge has done *nothing* wrong in this matter.
As for his short reply to the question, unfortunately this is for reasons outside his control.
Jeremy Allison,
Samba Team.
No Roger, you're not unsung or obscure.
:-).
:-).
:-). Even though his taste in toenail polish is *deplorable* :-).
You're just a git
To those who don't know, Roger Binns is responsible for Samba having the fastest share-mode lock code possible, as he goaded me into doing it by claiming it required a lock daemon. I was determined to prove him wrong...
Roger is also responsible for VisionFS (the *old*, good SCO's decent SMB file/print server).
Plus he holds a mean barbequeue
Jeremy.
I'm only going to say one thing here, and then leave it at that. As has been pointed out before, Luke has a very selective memory about his involvement with Samba.
Yes he made substantial contributions, for which we were very grateful, but in the end the difficulties in working together outweighed the benfits.
I'm not going to say any more - those who are interested can read the relevent email archives.
Jeremy.