Konstantin Khomoutov <flatw...@users.sourceforge.net> writes: > On Wed, 30 Dec 2015 13:34:29 +0300 > Dmitrii Kashin <d.kas...@solarsecurity.ru> wrote: > >> I didn't know where to put this question. It's not only >> debian-specific, but it concerns packaging in common. >> >> Our company is distributing some software splitted into packages (deb >> and rpm). Almost all files are installed into /opt/<prefix> and >> specifically all of them must be owned by some user <user>. >> >> My duty is to set up packaging of them all. And I have a problem: >> I'm using chroot environments to build out software, build process run >> under the root user and therefore all the files in /opt/<prefix> are >> owned by root. I need them to be owned by <user>. > > Do you *really* need this?
I hesitate, but yes. I do need specifically this. For now I'm solving other problem: I improved our build system to use chroot environments (to be pure and build packages in parallel), and I want to move it in production as soon as possible. That situation I've described above is how our product has been distributed for years; and if I try to fix specifically the problem with users, I'll stuck for a very long time, because lots of things will be broken. I understand the importance of the problem you described, and that it should be solved, and I'll try to find time to fix it to. But there's a big proglem to categorize all the files in project, because it's more than 32 thousands of them. > Hence I urge you to reconsider your approach, categorize the files your > project installs into the groups I outlined above and keep as tight > permissions as possible. To reiterate, suppose that the files of the > Apache web server would be owned by www-data, the standard Debian system > user to run web server software. Now should any exploit of any > dynamic *web site* run by Apache (let me repeat: not even a hole in the > server itself) allow an attacker to execute a script on your server (be > it PHP, Python or whatever else the site's engine is written in), they > will be able to overwrite /usr/sbin/apache unless it happens to be on a > filesystem mounted read-only. No kernel working exploit is needed at > all. Local users which will happen to own certain program files which > could also be run by administrators (with root credentials) might craft > a number of interesting attacks as well. Well it's a very good example! I'll use it to prove my employees to give me some time for this problem. Thank you.
