On Sat, May 10, 2014 at 10:32:26AM -0700, milki wrote: > On 17:23 Sat 10 May , brian m. carlson wrote: > > I don't believe this is possible. There has been some discussion on > > related matters at least fairly recently, though. > > > > Part of the reason nobody has implemented this is because it exposes > > additional security concerns. If I create a commit that references an > > object I don't own, but is in someone else's repository, this feature > > could allow me to gain access to objects which I shouldn't have access > > to unless the authentication and permissions layer is very, very > > careful. This would make many very simple HTTPS and SSH setups much > > more complex. Alternates don't have this problem because they're done > > server-side. > > If this were implemented service side and specified with, say, a config > option, would this security concern go away?
It would probably be fine if it were a config option. I'd prefer it be off by default, though, to prevent surprises. The attack scenario I'm thinking of is where you have several different users, but the web server runs as one system user. So /git/bmc/foo.git is owned by bmc, and /git/alice/bar.git is owned by alice. The web server will check authentication based on the path, and approve or deny it. If it's approved, it will invoke the git daemon as a CGI script. But the git daemon itself only knows that it was authenticated as a given user, and knows nothing about what the permissions scheme is. So it will blithely let me refer to any other repository and import its data if the option is enabled. The web server only considered the path it was fed, so it couldn't have blocked this. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
