Re: What is the correct way to set owner to package's files?
Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
> On Wed, 30 Dec 2015 13:34:29 +0300
> Dmitrii Kashin <d.kashin@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.
Reply to: