dos_mkdir(), was: 2.0.7: inherit permissions = yes breaks setting read-only on files

Robert Dahlem Robert.Dahlem at gmx.net
Thu Aug 24 16:39:52 GMT 2000


Michael,

[Subject adjusted to fit a little better]

On Thu, 24 Aug 2000 18:40:31 +0400, Michael Ju. Tokarev wrote:

>Robert Dahlem wrote:

>> In fact, at least Linux does not handle mkdir("dir", 0n777) with
>> n!=0 as expected: the mode seems to be and-ed with 0777.
>> 
>> I read you have access to some lot of operating systems. Could you
>> give mkdir("dir", 01777) a try?
>> 
>> From what I expect from such tests at the moment I see no need for
>> HAVE_BROKEN_MKDIR: if most operating systems need the additional
>> stat/chmod sequence anyway (which seems to be not too expensive
>> because dos_mkdir() won't be called too often in a production
>> environment) we can simply drop HAVE_BROKEN_MKDIR.

>Very interesting.   Ok, so maybe we should test for (mode & ~0777)
>before trying to do stat() and chmod()?  

Ok, that would save a stat() on newly created directorys when no high
bits were demanded.

Opposite point of view: without the test (mode & ~0777) you get at
least what was demanded even if the operating system dropped some of
the lower bits (as you outlined later in your mail when discussing
"really broken mkdir's").

>And probably should use regular unix stat() and chmod() instead of 
>dos_ ones...  

Why should we discard all those wrappers? Who knows which purposes they
will serve in future?

I'm not quite clear about the question if within the functions in
"all_those_wrappers.c" one should use the wrap_xxx() or the sys_xxx()
functions.

>Like this:
>
>int dos_mkdir(char *dname,mode_t mode)
>{
>  struct stat sbuf;
>  int ret = mkdir(dos_to_unix(dname,False),mode);
>  if(!ret && (mode & ~0777) && stat(dname,&sbuf) == 0 && (mode &
>~sbuf.st_mode))
>    chmod(dname, sbuf.st_mode | mode & ~sbuf.st_mode);
>  return ret;
>}

>But note note note note.  All that tricks with chmod() have tiny
>security hole.  This is very small hole, as chances to break it is
>very limited in time, but it _is_ exists.  Especially if high bits in
>mode involved.  If intruder can substitute (using just symlink) that
>newly created directory _before samba will call_ chmod with his file,
>it will be able to use samba's permissions.  Consider:
>
>  User joe have a set-uid file that can't be executed by scott.
>  Scott have access to shell and wants to execute that file.
>  Joe at this moment copies a bunch of files (with dirs) from his
>  machine using samba.  Scott knows that joe will create directory
>  "sd" in share /tmp.  So he (scott) can wait until this directory
>  will be created, and at this moment (very small timeslice) he can
>  remove that directory and replace it with a symlink to that file.
>  So, when samba calls chmod, it will change mode for a joe's file,
>  not for his newly directory.  High-bits exists in mode, so file
>  _can_ be made set-uid, and can be executable by scott.

I disagree on that: Scott needs a world-writeable (at least a
Scott-writable) directory to do this. Every adminstrator should know
that if you chmod 777 a directory you shoud also set the t-bit (01000)
on that directory to prevent this sort of security hole.

You should be able to test this on your solaris box:

    # cd /tmp
    # /bin/ls -ld .
    drwxrwxrwt   6 bin      bin         8192 Aug 24 18:15 .
... 777 but also t here ...
    # su joe -c "mkdir /tmp/testdir"
    # su scott -c "rmdir /tmp/testdir"
    rmdir: /tmp/testdir: Search or write permission needed

Any system not supporting the t-bit on directories is well known to be
exploitable in this point. From my point of view this is nothing samba
could cope with. And what I read some days ago here: samba should not
try to be a complete operating system (besides that whole discussion if
it should be just a file and print server or something more :-) .

>So, as a summary:

>= Almost all mkdirs are "broken" (or, maybe better, my understanding 
>of this was broken).

Yep. As far as I know ...

>= Supporting setting high-order bits with chmod have security 
>troubles; sticky-bit is only safe one to set here using chmod.

Nope. Not on systems coping with that sort of trouble.

>= There is no need to chmod if mode does not contain high-order bits,

Not as long as there is no "really broken mkdir".

>moreover, it will fail on some situations (like my example with
>msdos fs on linux).

That's a good point. With high bits it would fail anyway but since we
do not check for the return code of chmod() this "error" would not
reach the presentation level.

>= Maybe there are other systems that have really broken mkdir (that
>maybe ignores mode completely?), and for that systems we probably
>can have some workaround.

This is an argument against "mode & ~0777".

>I can't agree with this myself, since that broken mkdir if it exists 
>should be fixed at the first place.

Sometimes that's none of one' choices ...

>P.S.  I deleted samba at samba.org address from recipients list --
>this (long) discussion belongs to samba-technical.

Ok.

>And I can delete your (Robert's) address also, so that you will not 
>receive two copies of replies,

Please don't. I appreciate the private copy, it reaches me virtually
everywhere opposed to the mailing list.

Regards,
        Robert

---------------------------------------------------------------
Robert.Dahlem at gmx.net           Fax +49-69-432647
---------------------------------------------------------------






More information about the samba-technical mailing list