| delorie.com/archives/browse.cgi | search |
At 12:54 PM 5/24/00, you wrote: >"Larry Hall (RFK Partners, Inc)" wrote: > > [...] > > I guess I can only offer my opinion because I don't have any experience > > with this code. If writable_directory() is doing something wrong in both > > the ntsec and nontsec modes, it should be fixed (where eliminating it is > > 1 possible fix). If its doing something wrong for just ntsec cases, I'd > > say conditionalize it. I guess the big question that your description > > doesn't answer for me is, what do we loose by pulling it out as you > > describe? > >What we loose is the following: > >In UNIX/Linux you may not > remove a file, > rename a file, > mkdir a new subdir >if you don't have write permissions to the parent directory. > >In Windows you may all of the above. In Cygwin you are >actually disallowed that for being similar to U*X. > >What we loose is that a user is disallowed to do something >in Cygwin while s/he may do that when using cmd or Explorer >under the same conditions. > >The difference between ntsec and nontsec is that ntsec acts >(more or less) correct while nontsec only sets permission >bits and UID/GID to common values which _never_ results in >any problems with samba because the access function always >is sure that the user has sufficient permissions. > >Corinna I'm left with the impression that the best option is to use the writable_directory() call when ntsec is not enabled and skip it when it is. Sounds to me like it wreaks havoc on proper ntsec function but gets as close to UNIX behavior as possible for nontsec. If this is indeed a valid synopsis of the pros/cons of this case, my high level view of this conditionalize the use of writable_directory. Did I miss some important point? Larry
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |