We are planning to replace a quite big domain running W2K with Samba ( at the very least, the DC ). Though i'd love to have the extra security capabilities of W2K ( Kerberos ) as a DC, Samba/NT4 as PDC/BDC with ldapsam will more than suffice for now. The show-stopper right now is this: we need to be able to assign "real" Full Control permissions: a user who has "Full control" on a directory should be able to Read, Write, eXecute ( of course) [ this can be easily achieved with ACLs ] *plus* being able to give away Full Control to other users too [ being able to override inherited ACLs would be a plus, too ]. Is this feasible (remember smbd runs as root... )? Has somebody though about implementing this ? I thought that maybe coding a wrapper around SecLib could achieve this. Being quite fluent in C/C++ both in Un*x as well as Win32 I don't mind coding whatever tool is needed to achieve this, provided it is indeed possible. If not, some suggestions/comments ( or even an approximate timeline for implementation! ) would be more than welcome. Thanks in advance everybody. Keep the good work, Samba Team! Kind regards, J.L.
I Hate to reply myself, but since noone answered ...>We are planning to replace a quite big domain running W2K with Samba ( at >the very least, the DC ). > >Though i'd love to have the extra security capabilities of W2K ( Kerberos >) as a DC, Samba/NT4 as PDC/BDC with ldapsam will more than suffice for now. > >The show-stopper right now is this: we need to be able to assign "real" >Full Control permissions: a user who has "Full control" on a directory >should be able to Read, Write, eXecute ( of course) [ this can be easily >achieved with ACLs ] *plus* being able to give away Full Control to >other users too [ being able to override inherited ACLs would be a plus, >too ]. Is this feasible (remember smbd runs as root... )? Has somebody >though about implementing this ?Seems like every implementation of ACL comes together with Extended Attributes support ( at least Ext2/ext3, XFS, ReiserFS ). Any exceptions ? How about using one EA to map some Windows' attributes ? Full Control, Archive ( though it can be emulated through ctime/atime/mtime ), Change Only, come in a first pass over this.>I thought that maybe coding a wrapper around SecLib could achieve this. >Being quite fluent in C/C++ both in Un*x as well as Win32 I don't mind >coding whatever tool is needed to achieve this, provided it is indeed >possible. If not, some suggestions/comments ( or even an approximate >timeline for implementation! ) would be more than welcome.Any comments on this??>Thanks in advance everybody. >Keep the good work, Samba Team! > > >Kind regards, > J.L. > >-- >To unsubscribe from this list go to the following URL and read the >instructions: http://lists.samba.org/mailman/listinfo/samba
>>The show-stopper right now is this: we need to be >>able to assign "real" Full Control permissions: a >>user who has "Full control" on a directory should >>be able to Read, Write, eXecute ( of course) [ this >>can be easily achieved with ACLs ] *plus* being >>able to give away Full Control to other users too >>[being able to override inherited ACLs would be a >>plus, too]. Is this feasible (remember smbd runs as >>root... )? Has somebody thought about implementing >>this ?If you have Full Control over a directory (e.g. as root, or own it or have rwx on it), you can give FC (rwx) to others. Is it perhaps the other way around, that you want to stop this delegation, unless an FC EA explicitely allows it? I'm not sure if it can be a show-stopper or if it really makes a difference.>How about using one EA to map some Windows' >attributes ? Full Control, Archive ( though it can >be emulated through ctime/atime/mtime ), Change >Only, come in a first pass over this.Change Only? Uhm, you mean Erase Only? I wouldn't be surprised if there's an M$ ACL with that name. The EAs are apparently still a disputed novelty. Some M$ ACLs make sense, but Archive bit is nonsense and possibly much else. Consider the backslash, OK it's a different ball game but still, consider the backslash. Was there any need for it, given that Unix slash was in existence for decades when DOS came around? No, just like much of so called ACLs, it is a way to lock the installed base away from recognized standards to proprietary captivity. The way you put it, it looks like there are some major problems standing in the way of migrations to common standards, whereas it is my opinion that Samba is doing great by implementing sensible features in a standards-conforming way and offering an efficient file and print service for a song. Think about what really stops the show - the feature or the perception. Think how M$ may use your letter for FUD: "Samba is free but IT specialists complain they can't have full control of their data in practice".>>I thought that maybe coding a wrapper around SecLib >>could achieve this. Being quite fluent in C/C++ both >>in Un*x as well as Win32 I don't mind coding >>whatever tool is needed to achieve this, provided it >>is indeed possible. If not, some >>suggestions/comments ( or even an approximate >>timeline for implementation! ) would be more than >>welcome. > >Any comments on this??My posting was only comments. But go ahead and do it. Perhaps everyone will use it, once it's there. Samba isn't perfect. The way default permissions get replicated indiscriminately to subdirs and files is one thing that could be improved. If you want to ensure propagation of eXec (tresspassing) bit on directories, you eventually end up with Hidden, System and Archive bits stuck to files and still can't hide a directory or give it System attribute. But the problem is really only aesthetic. Hidden can and is regularly overridden in the file browser properties box, Archive I couldn't care less about and the System bit has nothing to do in most of the shares, except perhaps in [profiles] where you don't need ACLs anyway. When I was migrating, everyone thought it was a sure show-stopper. Now after some hands-on experience and a little tweaking, the perception has changed and there is no problem. ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005
>> consider the backslash. Was there any need for it, >> given that Unix slash was in existence for decades >> when DOS came around? No, just like much of so >> called ACLs, it is a way to lock the installed base >> away from recognized standards to proprietary >> captivity. > >In July 1981, Microsoft bought all rights to DOS from >Seattle Computer. I doubt Seattle Computer had any >intention of locking in the installed base with >backslashes.Thanks for the correction. But was backslash used as path separator in ur-DOS? Just curious. ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005
I suspect the backslash thing actually ties back to DOS 1.0 and even CP/M, which had user-interface roots in the old DEC operating systems. Those OS's used forward slash as the "option" indicator on command line utilities. In their earliest form, neither had hierarchical directories, so there was no conflict. When UNIX-style paths appeared in DOS 2.0, to avoid breaking compatibility with existing BAT files (and confusing users), IBM (or whoever) used the backslash for the path separator.> -----Original Message----- > From: Dragan Krnic [mailto:dkrnic@lycos.com] > Sent: Wednesday, June 18, 2003 11:05 AM > To: Michael MacIsaac > Cc: samba@lists.samba.org > Subject: Re: [Samba] Re: Full wNT/w2K ACL conformance > > > >> consider the backslash. Was there any need for it, > >> given that Unix slash was in existence for decades > >> when DOS came around? No, just like much of so > >> called ACLs, it is a way to lock the installed base > >> away from recognized standards to proprietary > >> captivity. > > > >In July 1981, Microsoft bought all rights to DOS from > >Seattle Computer. I doubt Seattle Computer had any > >intention of locking in the installed base with > >backslashes. > > Thanks for the correction. But was backslash used > as path separator in ur-DOS? Just curious. > > > ____________________________________________________________ > Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! > http://login.mail.lycos.com/r/referral?aid=27005 > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba >
>UH-OH! Maybe it's IBM's fault: > >Those OS's used forward slash as the "option" >indicator on command line utilities. In their >earliest form, neither had hierarchical directories, >so there was no conflict. When UNIX-style paths >appeared in DOS 2.0, to avoid breaking compatibility >with existing BAT files (and confusing users), IBM >(or whoever) used the backslash for the path >separator.Here we go again: why slash and not dash? Seattle Computers had global ulterior designs for sure {:-) Thanks. ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005
"Never attribute to malice that which can adequately be explained by stupidity." Or in this case, an attempt at compatibility for users who had come from the DEC minicomputer world. DOS 1.0 took a lot of it's command line conventions from CP/M, which got them from the old DEC stuff. RT-11, OS-8, etc. UNIX wasn't really on anyone's radar screen at that point, at least not for PC's. There's no logic here, just however someone felt like doing it. No "usability studies", and design-by-committee in those days. Can you imagine a review committee letting someone get away with "ls", "cat", and "grep" these days? DIR and TYPE at least made some sense, even if "PIP" didn't. :)> -----Original Message----- > From: Dragan Krnic [mailto:dkrnic@lycos.com] > Sent: Wednesday, June 18, 2003 12:26 PM > To: Michael MacIsaac > Cc: samba@lists.samba.org > Subject: [Samba] Re: Full wNT/w2K ACL conformance > > > >UH-OH! Maybe it's IBM's fault: > > > >Those OS's used forward slash as the "option" > >indicator on command line utilities. In their > >earliest form, neither had hierarchical directories, > >so there was no conflict. When UNIX-style paths > >appeared in DOS 2.0, to avoid breaking compatibility > >with existing BAT files (and confusing users), IBM > >(or whoever) used the backslash for the path > >separator. > > Here we go again: why slash and not dash? Seattle > Computers had global ulterior designs for sure {:-) > > Thanks. > > > ____________________________________________________________ > Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! > http://login.mail.lycos.com/r/referral?aid=27005 > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba >