Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thomas Glanzmann <thomas@xxxxxxxxxxxx> writes:

> Hello,
> might that be related to the problem:
>
>
>         lstat64("profiles/icpc", 0xFFBFF350)            Err#2 ENOENT
> =>       mkdir("profiles", 0777)                         = 0
>         stat64(".git/objects/66/6197b02f46c92f0273f16ac77d34d76b28f4f0",
>         0xFFBFF088) = 0
>         open64(".git/objects/66/6197b02f46c92f0273f16ac77d34d76b28f4f0",
>         O_RDONLY) = 4
>         mmap64(0x00000000, 284, PROT_READ, MAP_PRIVATE, 4, 0) = 0xFF230000
>         close(4)                                        = 0
>         munmap(0xFF230000, 284)                         = 0
>         open64("profiles/icpc", O_WRONLY|O_CREAT|O_EXCL, 0666) = 4
>         open64("profiles/.gitattributes", O_RDONLY)     Err#2 ENOENT
>         write(4, " #   I C P C   P r o f i".., 420)     = 420
>         close(4)                                        = 0
>         lstat64("profiles/sithglan", 0xFFBFF350)        Err#2 ENOENT
> =>      mkdir("profiles", 0777)                         Err#17 EEXIST
> =>      unlink("profiles")                              = 0
> =>      mkdir("profiles", 0777)                         = 0
>
> I think it is. Damn it. What seems to hapen here is that git does:
>
>         - create a subdirectory
>         - puts a file in
>         - deletes a subdirectory (by call unlink - that would normally fail,
>           but with solaris as root it does not fail)
>
>                 => here comes the dangling hard link counter
>
>         - created the directory again
>         - puts the file in
>
> That is why I only see one file in each subdirectory (the one that got
> checkedout last). So the fix for git should be straight forward. But I still
> think that Solaris is obviously broken. Because if you ask me it should not be
> possible to unlink a directory that has files in it?!

<URL:http://www.opengroup.org/onlinepubs/000095399/functions/unlink.html>

    The path argument shall not name a directory unless the process has
    appropriate privileges and the implementation supports using unlink()
    on directories.

So Solaris has the right to do this.

    APPLICATION USAGE

        Applications should use rmdir() to remove a directory.

    RATIONALE

        Unlinking a directory is restricted to the superuser in many
        historical implementations for reasons given in link() (see
        also rename()).


In short: git should not call remove, ever.  It may succeed, and is a
badly low-level call.  If something is known to be a directory, then
it needs to be removed using rmdir, and if it is a nondirectory, with
unlink.

Hm, browsing through Posix indicates that unlink is probably the same
as remove.  Pity.  I thought that just "remove" was the potential
evildoer.

-- 
David Kastrup

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux