At Sat, 18 Jan 2014 10:33:45 -0500, Luke T. Shumaker wrote: > The > reason they didn't experience this before is that because of the bugs, > things were getting "needlessly" `cp`ed around as `root`, so when > `nobody` eventually had to read them, the file permissions were OK, as > the umask had been set to 022 before copying them.
That's not entirely true. The files themselves were readable, but it was the directory they were in that was not. Even typing that should have set off some internal BS-meter; cp will by default preserve file permissions, not obey umask. > Now the question is what to do about it. Options: > > 2. Add a check to make sure the file permissions are OK, and bail if > they aren't. > Pros: > - Simple This is the method I am going with, at least for now, as two of the cons aren't true, as I think about them more: > Cons: > - Clear reduction of functionality It still is. :( > - Pain for existing users to transition Git tracks the permissions of the files--there's not a whole ABS tree that they need to convert, and there aren't files they need to convert. It's likely one or two directories that that they need to chmod/setfacl. > - Basically mandates a lenient umask, bad for security Except it doesn't. Like I said, git tracks the file permissions. Makepkg sets the umask. The only directories that need to be changed are one-time setups (SRCDEST). The remaining options all involved changing permissions behind users' backs, which feels *really* dirty to me. Happy hacking, ~ Luke Shumaker _______________________________________________ Dev mailing list [email protected] https://lists.parabolagnulinux.org/mailman/listinfo/dev
