{"thread":{"id":"58169","subject":"'git clone,' build makes user non-writable files (should be option keep user-writable)","startedAt":"2022-07-15T10:36:01Z","lastAt":"2022-08-09T11:06:24Z","messageCount":8,"participants":["David Chmelik","Beat Bolli","Chris Torek","Đoàn Trần Công Danh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"459134","messageId":"822787da-bc26-0d72-a5c4-808a3d10126e@gmail.com","threadId":"58169","inReplyTo":null,"subject":"'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"David Chmelik","fromEmail":"dchmelik@gmail.com","sentAt":"2022-07-15T10:35:49Z","receivedAt":"2022-07-15T10:36:01Z","isPatch":false,"sender":{"key":"dchmelik@gmail.com","avatar":null},"body":"What did you do before the bug happened?\n'git clone,' built various software (with gcc, BSD & GNU make, \nautotools, cmake, etc.)\n\nWhat did you expect to happen?\nOption: keep cloned/built/etc. files user-writable.\n\nWhat happened instead?\nNeeded chmod or 'sudo rm -rf.'\n\nWhat's different between what you expected and what actually happened?\nOption: keep cloned/built/etc. files user-writable, otherwise (has been \nsaid 15+ years) encourages 'sudo rm -rf.'\n\nAnything else you want to add:\n         I try/test/debug (and report bugs) many software commits but \ndon't commit so need cloned/built/etc. files writable as user & even \nsystem-wide options: who hasn't made 'rm -rf' mistakes? (unrelated but \nsomeone might claim is: I don't use non-UNIX-like OS that shell alias \n'rm -rf' to confirm every file (potentially thousands) and though made \nmy own alias (confirm once) it's longer, sometimes unavailable so don't \nalways use (many people don't)... software should always have \nuser-writable files option.)  Below indicates GNU/Linux but also have \noften used git on *BSD/Unix.  I'm not on git mailing list but you can CC \nme all replies.\n\n[System Info]\ngit version:\ngit version 2.37.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.18.11 #1 SMP PREEMPT_DYNAMIC Wed Jul 13 00:20:29 CDT 2022 \nx86_64\ncompiler info: gnuc: 12.1\nlibc info: glibc: 2.35\n$SHELL (typically, interactive shell): /bin/bash\n\n"},{"id":"459221","messageId":"YtPwp/OSD2X6Q/Ol@zbox.drbeat.li","threadId":"58169","inReplyTo":"822787da-bc26-0d72-a5c4-808a3d10126e@gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"Beat Bolli","fromEmail":"dev@drbeat.li","sentAt":"2022-07-17T11:21:11Z","receivedAt":"2022-07-17T11:28:13Z","isPatch":false,"sender":{"key":"dev@drbeat.li","avatar":null},"body":"On Fri, Jul 15, 2022 at 03:35:49AM -0700, David Chmelik wrote:\n\n[resend with reply-to-all]\n\n> What did you do before the bug happened?\n> 'git clone,' built various software (with gcc, BSD & GNU make, autotools,\n> cmake, etc.)\n> \n> What did you expect to happen?\n> Option: keep cloned/built/etc. files user-writable.\n> \n> What happened instead?\n> Needed chmod or 'sudo rm -rf.'\n> \n> What's different between what you expected and what actually happened?\n> Option: keep cloned/built/etc. files user-writable, otherwise (has been said\n> 15+ years) encourages 'sudo rm -rf.'\n> \n> Anything else you want to add:\n>         I try/test/debug (and report bugs) many software commits but don't\n> commit so need cloned/built/etc. files writable as user & even system-wide\n> options: who hasn't made 'rm -rf' mistakes? (unrelated but someone might\n> claim is: I don't use non-UNIX-like OS that shell alias 'rm -rf' to confirm\n> every file (potentially thousands) and though made my own alias (confirm\n> once) it's longer, sometimes unavailable so don't always use (many people\n> don't)... software should always have user-writable files option.)  Below\n> indicates GNU/Linux but also have often used git on *BSD/Unix.  I'm not on\n> git mailing list but you can CC me all replies.\n\nWhen building software as the current user, the build artefacts are\nowned by this user.\n\nAre you building the software using Docker containers that run as root?\n\nRegards, Beat\n"},{"id":"459777","messageId":"158251f2-9fa4-45b7-4c24-907c94602b6e@gmail.com","threadId":"58169","inReplyTo":"YtPtQ6qsIviyTBF2@zbox.drbeat.li","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"David Chmelik","fromEmail":"dchmelik@gmail.com","sentAt":"2022-07-22T13:23:05Z","receivedAt":"2022-07-22T13:23:19Z","isPatch":false,"sender":{"key":"dchmelik@gmail.com","avatar":null},"body":"On 7/17/22 4:06 AM, Beat Bolli wrote:\n> On Fri, Jul 15, 2022 at 03:35:49AM -0700, David Chmelik wrote:\n>> What did you do before the bug happened?\n>> 'git clone,' built various software (with gcc, BSD & GNU make, autotools,\n>> cmake, etc.)\n>>\n>> What did you expect to happen?\n>> Option: keep cloned/built/etc. files user-writable.\n>>\n>> What happened instead?\n>> Needed chmod or 'sudo rm -rf.'\n>>\n>> What's different between what you expected and what actually happened?\n>> Option: keep cloned/built/etc. files user-writable, otherwise (has been said\n>> 15+ years) encourages 'sudo rm -rf.'\n>>\n>> Anything else you want to add:\n>>          I try/test/debug (and report bugs) many software commits but don't\n>> commit so need cloned/built/etc. files writable as user & even system-wide\n>> options: who hasn't made 'rm -rf' mistakes? (unrelated but someone might\n>> claim is: I don't use non-UNIX-like OS that shell alias 'rm -rf' to confirm\n>> every file (potentially thousands) and though made my own alias (confirm\n>> once) it's longer, sometimes unavailable so don't always use (many people\n>> don't)... software should always have user-writable files option.)  Below\n>> indicates GNU/Linux but also have often used git on *BSD/Unix.  I'm not on\n>> git mailing list but you can CC me all replies.\n> When building software as the current user, the build artefacts are\n> owned by this user.\nOwnership, permissions are different: one can own files yet have zero \npermission to write/delete and be denied that.  After cloning, \narchiving, building most/all projects I tried from (hundreds/thousands) \ngit commits I typically/always had zero permission to write/delete some \nfiles/directories within--despite owning--which led to more steps to \ndelete and temptation to sudo 'rm -rf' (or preferably alias or script \nsuch as 'rm -RfI' (FreeBSD UNIX) or 'rm -rf --interactive=once' (GNU) \nbut may not always be available).\n\n> Are you building the software using Docker containers that run as root?\nI don't use containers.  I noticed some projects' cmake & 'sudo make \ninstall' put root-owned files in build directory but doesn't seem to \nhappen with other build systems--especially not plain make (BSD nor GNU \nnor with autotools)--still-used by almost all projects I try commits from.\n         So, I don't think root is the problem; IIRC usually problem was \ncloned directories had one or more subdirectories (such as .git* or \nfiles/subdirectories further in those) that were/became user \nnon-writeable so I ended up writing a bash function (on SlackWiki.com & \ndocs.Slackware.com) to make git clones user-writable: should be by \ndefault (before & after building in .git*, etc.) and/or a \nwell-documented beginner/easy option (is it even an option?) because \nsurely many more people only test than commit.  Instructions say 'git \nclone URL' assuming someone will commit rather than only test and want \nto avoid user-non-writeable files (I doubt I even need .git* \nsubdirectories until ever start committing (don't plan to: I only like \ndecimal-numbered tarballs made manually rather than version control) so \nwould rather opt-out).  I don't recall commits from three other/older \nmajor version control systems be(com)ing user non-writeable (though all \nless-used apart from on classic UNIX/*BSD I don't use much anymore \nbesides servers but wish had more hardware support to be more \ndesktop-useable).\n"},{"id":"459806","messageId":"ccbc1e81-b406-9e73-7aa5-956ffae7074b@gmail.com","threadId":"58169","inReplyTo":"CAPx1Gvc6ci1CjhL-zjwqkR=4o2yQTrT0V_Hb9bUBNuaBn47M8A@mail.gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"David Chmelik","fromEmail":"davidnchmelik@gmail.com","sentAt":"2022-07-23T00:25:35Z","receivedAt":"2022-07-23T00:25:47Z","isPatch":false,"sender":{"key":"davidnchmelik@gmail.com","avatar":"https://gravatar.com/avatar/a1a00f598e7857f182e7491425cbc449b0020d6990b7278e44fbfb2fb2977d57?d=mp&s=160"},"body":"On 7/22/22 10:40 AM, Chris Torek wrote:\n> On Fri, Jul 22, 2022 at 6:24 AM David Chmelik <dchmelik@gmail.com \n> <mailto:dchmelik@gmail.com>> wrote:\n>\n>     Ownership, permissions are different: one can own files yet have zero\n>     permission to write/delete and be denied that. ...\n>\n>\n> All true.  But Git has no control over, or affect on these: Git does\n> not attempt to affect ownership or permission of any build products\n> at all.  Git only attempts to affect the execute permission of\n> specific files as directed by the committed file mode (and provided\n> `core.filemode` is enabled).\nNot even projects' .git* subdirectories?  They typically are/become \nuser-non-writable though deletable with several/many confirmations so I \nusually sudo (recommended against).  I'd rather opt-out of .git* \nsubdirectories for every clone.\n\n> [...] If you're using Samba/CIFS or other ACL-based file servers [...]\nI don't know what those are (other than once tried Samba to transfer \nfiles between home PCs, not for compiling).\n"},{"id":"459821","messageId":"CAPx1GvceFLRL_O5zYW98tPdNV9S_Y=fChJafsq+HGkEYixKsZA@mail.gmail.com","threadId":"58169","inReplyTo":"ccbc1e81-b406-9e73-7aa5-956ffae7074b@gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2022-07-23T03:54:17Z","receivedAt":"2022-07-23T03:54:35Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Fri, Jul 22, 2022 at 5:29 PM David Chmelik <davidnchmelik@gmail.com> wrote:\n> On 7/22/22 10:40 AM, Chris Torek wrote:\n> > All true.  But Git has no control over, or affect on these: Git does\n> > not attempt to affect ownership or permission of any build products\n> > at all.  Git only attempts to affect the execute permission of\n> > specific files as directed by the committed file mode (and provided\n> > `core.filemode` is enabled).\n> Not even projects' .git* subdirectories?  They typically are/become\n> user-non-writable though deletable with several/many confirmations so I\n> usually sudo (recommended against).\n\nAh, I thought you were (and I definitely was) talking only about the\n*build products*. The stuff inside `.git` itself: some of that, Git does set\nto non-writable. There is no need to use `sudo` though: a simple\n\"rm -rf .git\" will blow away the Git repository itself.  However:\n\n> I'd rather opt-out of .git* subdirectories for every clone.\n\nIn that case, *don't run `git clone in the first place*. The purpose of\n`git clone` is to get you the entire repository. If you want a single working\ntree, use `git archive` to make an archive from the commit you want,\nand extract that archive to get the tree you want, without getting all\nthe *other* revisions.\n\nChris\n"},{"id":"459822","messageId":"Ytt09IrDyEQDc3Z3@danh.dev","threadId":"58169","inReplyTo":"158251f2-9fa4-45b7-4c24-907c94602b6e@gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2022-07-23T04:11:32Z","receivedAt":"2022-07-23T04:11:40Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2022-07-22 06:23:05-0700, David Chmelik <dchmelik@gmail.com> wrote:\n> On 7/17/22 4:06 AM, Beat Bolli wrote:\n> > On Fri, Jul 15, 2022 at 03:35:49AM -0700, David Chmelik wrote:\n> > > What did you do before the bug happened?\n> > > 'git clone,' built various software (with gcc, BSD & GNU make, autotools,\n> > > cmake, etc.)\n> > > \n> > > What did you expect to happen?\n> > > Option: keep cloned/built/etc. files user-writable.\n> > > \n> > > What happened instead?\n> > > Needed chmod or 'sudo rm -rf.'\n> > > \n> > > What's different between what you expected and what actually happened?\n> > > Option: keep cloned/built/etc. files user-writable, otherwise (has been said\n> > > 15+ years) encourages 'sudo rm -rf.'\n> > > \n> > > Anything else you want to add:\n> > >          I try/test/debug (and report bugs) many software commits but don't\n> > > commit so need cloned/built/etc. files writable as user & even system-wide\n> > > options: who hasn't made 'rm -rf' mistakes? (unrelated but someone might\n> > > claim is: I don't use non-UNIX-like OS that shell alias 'rm -rf' to confirm\n> > > every file (potentially thousands) and though made my own alias (confirm\n> > > once) it's longer, sometimes unavailable so don't always use (many people\n> > > don't)... software should always have user-writable files option.)  Below\n> > > indicates GNU/Linux but also have often used git on *BSD/Unix.  I'm not on\n> > > git mailing list but you can CC me all replies.\n> > When building software as the current user, the build artefacts are\n> > owned by this user.\n> Ownership, permissions are different: one can own files yet have zero\n> permission to write/delete and be denied that.  After cloning, archiving,\n> building most/all projects I tried from (hundreds/thousands) git commits I\n> typically/always had zero permission to write/delete some files/directories\n> within--despite owning--which led to more steps to delete and temptation to\n> sudo 'rm -rf' (or preferably alias or script such as 'rm -RfI' (FreeBSD\n> UNIX) or 'rm -rf --interactive=once' (GNU) but may not always be available).\n> \n> > Are you building the software using Docker containers that run as root?\n> I don't use containers.  I noticed some projects' cmake & 'sudo make\n> install' put root-owned files in build directory but doesn't seem to happen\n\ncmake & sudo make install\n\nis your problem\n\ncmake only generate a build system for your project.\nAfter that, you need to run make to build its artifarts before running\n(sudo) make install.\n\nIf you don't run `make` first, `make install` will trigger `make all`\nimplicitly, since `install` target depends on `all` target.\nThus, `sudo make install` will invoke some sort of equivalence of\n`sudo make`, thus all build output will be owned by root.\n\nSo, there're nothing to do with git.\n\n\n> with other build systems--especially not plain make (BSD nor GNU nor with\n> autotools)--still-used by almost all projects I try commits from.\n>         So, I don't think root is the problem; IIRC usually problem was\n> cloned directories had one or more subdirectories (such as .git* or\n> files/subdirectories further in those) that were/became user non-writeable\n> so I ended up writing a bash function (on SlackWiki.com &\n> docs.Slackware.com) to make git clones user-writable: should be by default\n> (before & after building in .git*, etc.) and/or a well-documented\n> beginner/easy option (is it even an option?) because surely many more people\n> only test than commit.  Instructions say 'git clone URL' assuming someone\n> will commit rather than only test and want to avoid user-non-writeable files\n> (I doubt I even need .git* subdirectories until ever start committing (don't\n> plan to: I only like decimal-numbered tarballs made manually rather than\n> version control) so would rather opt-out).  I don't recall commits from\n> three other/older major version control systems be(com)ing user\n> non-writeable (though all less-used apart from on classic UNIX/*BSD I don't\n> use much anymore besides servers but wish had more hardware support to be\n> more desktop-useable).\n\n-- \nDanh\n"},{"id":"460432","messageId":"c0bc2741-092b-273c-ddf4-a2c9d90da6bf@gmail.com","threadId":"58169","inReplyTo":"CAPx1GvceFLRL_O5zYW98tPdNV9S_Y=fChJafsq+HGkEYixKsZA@mail.gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"David Chmelik","fromEmail":"davidnchmelik@gmail.com","sentAt":"2022-08-02T14:34:55Z","receivedAt":"2022-08-02T14:35:10Z","isPatch":false,"sender":{"key":"davidnchmelik@gmail.com","avatar":"https://gravatar.com/avatar/a1a00f598e7857f182e7491425cbc449b0020d6990b7278e44fbfb2fb2977d57?d=mp&s=160"},"body":"On 7/22/22 8:54 PM, Chris Torek wrote:\n> On Fri, Jul 22, 2022 at 5:29 PM David Chmelik<davidnchmelik@gmail.com>  wrote:\n>> On 7/22/22 10:40 AM, Chris Torek wrote:\n>>> All true.  But Git has no control over, or affect on these: Git does\n>>> not attempt to affect ownership or permission of any build products\n>>> at all.  Git only attempts to affect the execute permission of\n>>> specific files as directed by the committed file mode (and provided\n>>> `core.filemode` is enabled).\n>> Not even projects' .git* subdirectories?  They typically are/become\n>> user-non-writable though deletable with several/many confirmations so I\n>> usually sudo (recommended against).\n> Ah, I thought you were (and I definitely was) talking only about the\n> *build products*. The stuff inside `.git` itself: some of that, Git does set\n> to non-writable.\nInitially wasn't; don't know why took three replies to clear up \n(initially clearly specified non-root usage which others ignored and \nmentioned/focused unrelated root topic).\n\n> There is no need to use `sudo` though: a simple\n> \"rm -rf .git\" will blow away the Git repository itself.  However:\nStill fewer confirmations with sudo (one rather than every single \nuser-non-writable file).\n\n>> I'd rather opt-out of .git* subdirectories for every clone.\n> In that case, *don't run `git clone in the first place*. The purpose of\n> `git clone` is to get you the entire repository. If you want a single working\n> tree, use `git archive` to make an archive from the commit you want,\n> and extract that archive to get the tree you want, without getting all\n> the *other* revisions.\nSeems much more complicated (and less-documented) and most popular git \nsites (though the #1 isn't Free/Libre/Opensource Software (FLS, OSS, \nFOSS, FLOSS) so is condemned) allow clone but not archive.  I know you \ncan't control their mistakes and they should be irrelevant \n(unfortunately most projects use most popular/broken sites) but couldn't \nthere be more (detailed and/or easier) syntax?\n"},{"id":"460888","messageId":"b47b88fb-89bd-732c-3aeb-75a474a7fdb5@gmail.com","threadId":"58169","inReplyTo":"CAPx1GvceFLRL_O5zYW98tPdNV9S_Y=fChJafsq+HGkEYixKsZA@mail.gmail.com","subject":"Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)","fromName":"David Chmelik","fromEmail":"davidnchmelik@gmail.com","sentAt":"2022-08-09T11:05:46Z","receivedAt":"2022-08-09T11:06:24Z","isPatch":false,"sender":{"key":"davidnchmelik@gmail.com","avatar":"https://gravatar.com/avatar/a1a00f598e7857f182e7491425cbc449b0020d6990b7278e44fbfb2fb2977d57?d=mp&s=160"},"body":"On 7/22/22 8:54 PM, Chris Torek wrote:\n> On Fri, Jul 22, 2022 at 5:29 PM David Chmelik<davidnchmelik@gmail.com> \n> wrote:\n>> On 7/22/22 10:40 AM, Chris Torek wrote:\n>>> All true. But Git has no control over, or affect on these: Git does\n>>> not attempt to affect ownership or permission of any build products\n>>> at all. Git only attempts to affect the execute permission of\n>>> specific files as directed by the committed file mode (and provided\n>>> `core.filemode` is enabled).\n>> Not even projects' .git* subdirectories? They typically are/become\n>> user-unwritable though deletable with several/many confirmations so I\n>> usually sudo (recommended against).\n> Ah, I thought you were (and I definitely was) talking only about the\n> *build products*. The stuff inside `.git` itself: some of that, Git \n> does set\n> to unwritable.\nInitially wasn't; don't know why took three replies to clear up \n(initially clearly specified non-root usage which others ignored and \nmentioned/focused unrelated root topic).\n\n> There is no need to use `sudo` though: a simple\n> \"rm -rf .git\" will blow away the Git repository itself. However:\nStarts with 'rm -rf .' which is bad and worse is one key away from 'rm \n-rf /': anyone who accidentally pressed <ENTER> after either what I put \nin quotation marks (I did both as root on my personal files and entire \nPC in 1990s... have you ever?  It was normal to use root account then \nrather than non-UNIX-like OS that lock it) wants to never again so \ntypically uses alias which done with sudo (still considered worst last \nresort) still has fewer confirmations (one rather than every single \nuser-unwritable file). I can't believe I'm asking to encourage avoid 'rm \n-rf', on mailing list of a tool on UNIX/GNU/Linux (POSIX-based) \noperating systems, original which people started avoiding 'rm -rf' in \n1970s, but now people say just do it!\n\n>> I'd rather opt-out of .git* subdirectories for every clone.\n> In that case, *don't run `git clone in the first place*. The purpose of\n> `git clone` is to get you the entire repository. If you want a single \n> working\n> tree, use `git archive` to make an archive from the commit you want,\n> and extract that archive to get the tree you want, without getting all\n> the *other* revisions.\nSeems much more complicated (and less-documented) and most popular git \nsites (though #1 isn't Free/Libre/Opensource Software (FLS, OSS, FOSS, \nFLOSS) so rightly condemned) disallow archive.  Though I my shell alias \nrewrites 'git clone' to then 'chmod u+w .git*' or alternatively 'find . \n-iname .git* -perm u-w -exec chmod u+w {} \\+' and usually before \narchiving, 'sudo rm -rf .git*', aliases are sometimes unavailable and \nnow a few projects won't compile without such directories.  I know you \ncan't control popular sites' mistakes (nor projects never doing \nnormally-numbered releases) and they should be irrelevant: unfortunately \nmost projects use most popular/broken sites, sadly including core \ncomponent projects for some/most/all POSIX-based OSs, so couldn't syntax \nbe easier/detailed so testers can opt-out user-unwritables (for \nthousands/millions major cases archive disallowed)?\n         Apparently many/all version control systems (VCS) make such \n(initially) user-unwritables so may consider this request odd but for \ntester-only people, it's not odd to dislike such we don't use (unless \never changes... I've used VCS last  11+ years (likely since late 1990s \nor early '0s) and don't plan to use .git* & etc. decades into \nforeseeable future but in very-slight chance I do presumably such \nfiles/directories would be useful... for now I've spent hours/days over \ndecades in frustration: 11+ years ago when projects had a minor bug said \n'try from VCS (nightly)' I was glad but led to nightly/critical bugs and \nuser-unwritables... VCS are a godsend for decreasing years update waits \nbut (as with most science/technology) have advantages & disadvantages...)\n--D\n\n"}]}