How to automatically execute commands that require "su" privileges during user login.

[First_Law_of_Unix]

Hello,

I couldn't find any information from the web on how to make a shell script which can automatically execute commands that require "su" privileges during user login.

I have read that I can store the shell script at "/etc/profile.d/" location which did not exist by default and I had to create one. However, I did so and the script does not load during login.

Here is my script:

#!/bin/sh
webcamd -c v4l2loopback

This is the directory location where I stored it:
/etc/profile.d/v4l2loopback_1.sh

The usage of "/etc/profile.d/" and documentation conjecture of it from the FreeBSD man page doesn't go into details:

profile(4)

www.freebsd.org

Basically what I would like to do is to run the following command automatically which requires to be run as root/su user:
webcamd -c v4l2loopback

The above command is weird, you can not close the terminal and it needs to be actively running with the terminal open. If the terminal is closed using "ctrl-z", the entire "webcamd" services will crash and have no idea how to fix it, need to restart FreeBSD again. So basically I need to run this command as a background service/process and should only start when user logins.

Also, I would like to automatically execute commands at/during user login not during system startup or boot phase.
Need it to be both for FreeBSD console login and also for GUI KDE Desktop environment login as well.

I would like to run the command in a custom created script file, do not like the idea to put script lines of code for custom software in system related script files which contains code already for system related services, it is messy and not my way for simplicity and proper organization. Would like to create scripts and place it in a location if possible.

As of now, I would like the script file to take in effect for the entire user community or for specific user, does not matter.

Thanks for any information.

 

[gpw928]

Maybe rethink your approach? vermaden has some potentially valuable insight.

 

[First_Law_of_Unix]

Will look into it, thanks.

Edit:
Alright, I have seen the website. It does have good information on how to get webcams working.

But my issue is not related to webcam specifically. It is about creating scripts that runs commands which requires to be root. I need to know how to do this on FreeBSD because it is an essential knowledge needed for making custom programs that requires full control of the FreeBSD OS.

Making a DVR surveillance system where the PC is solely based on being a DVR running on FreeBSD OS. I also need to run other commands not just related to webcamd which requires root user authentication. I know in linux, it is possible to place the script file in the "sodoers" list which makes the script file run root user commands without requiring root authentication. Wonder how FreeBSD does this on it's native way/tools.

 

[Phishfry]

Not native FreeBSD but a port. Comes from OpenBSD,

doas(1)

www.freebsd.org

doas.conf(5)

www.freebsd.org

 

[First_Law_of_Unix]

Not native FreeBSD but a port. Comes from OpenBSD,

doas(1)

www.freebsd.org

doas.conf(5)

www.freebsd.org

Thank You. I happened to read that previously and was thinking to implement it. Just wanted to make sure what the pros had to say before using linux's soders(sudo) or doas. I guess I should just use tools ported to freebsd to do the task.

However, I have found the most native way in doing it on FreeBSD without requiring any ported tools.

The implementation is to write the shell script in a "C" code file and compile it with the "suid" bit set in place. I think this is a win-win since I am programming in C/C++ to begin with.

C/C++ being able to run shell scripts/commands which requires root authentication without being a root user seems to do the job for me. It is also much simpler overall in my opinion than having to play with linux's soders(sudo) or doas. I also need to read and learn how to set the "suid" bit to the "C/C++" compiled executable under FreeBSD.

Here are the sources where I got the information from and tested it which actually works on FreeBSD 13.1 for which the compiled "C" code runs terminal commands:

How to execute a shell script from C in Linux?

How can I execute a shell script from C in Linux?

stackoverflow.com

UNIX.COM Message

www.unix.com

However I do not know if this is just as secure as to using ported tools like soders(sudo) or "doas".

 

[Phishfry]

In a similar vein you are aware of /etc/rc.local correct?

rc.local(8)

www.freebsd.org

 

[First_Law_of_Unix]

Yes, but I read that /etc/rc.local is only for services that can start at boot phase and not for user login phase. Scripts to be only run during a user login are at /etc/profile.d/ or ~/.profile or /etc/profile (can't find any detailed manual for the "profile" implementation.).

I also read that for GUI KDE DEs for which commands to be executed during user logins, I would need to thinker in ~/.xprofile but this alone does not solve for user logins from the FreeBSD terminal not using GUI DEs.

 

[gpw928]

If all you want to achieve is to run a command as root, then doas(1) and sudo(8) both work the same way as in Linux.

Things that happen at every login are also the same as for Linux, and the mechanisms are entirely dependent on your login shell. Read the manual page for your shell of choice.

When you wish to control hardware, it's usually best done with a daemon, usually started at boot time. That's why I mentioned vermaden's post first.

 

[First_Law_of_Unix]

If all you want to achieve is to run a command as root, then doas(1) and sudo(8) both work the same way as in Linux.

Indeed, now I can use doas(1) and sudo(8), but now I have a delima when it comes to security, are they just as vulnerable when I can run root commands via C/C++ code with the compiled code suid bit set?

I ask since running root commands via C/C++ is so much easier and organized for me, since the main project runs in C/C++.

 

[gpw928]

In the great scheme of things, the mechanism by which a process gets its effective UID set to zero (i.e. root) does not really matter.

Once it's set to zero, it will have all the power and (potentially in)glory.

However, processes written by experts expecting to run as root, like many daemons, are probably more likely to be planned, written, and tested to be secure...

 

[msplsh]

If there's a way to not set the UID bit to root, then do that. Don't avoid a solution just because it doesn't "smell native" to FreeBSD. You're aware what the first L stands for in the command you're running, correct?

 

[First_Law_of_Unix]

You're aware what the first L stands for in the command you're running, correct?

Video 4 Linux 2

Trust me, I wouldn't use it if there where native ways to do so. I need video loopback and so far to get the job done, I need to use v4l2loopback on FreeBSD.

Such as "pwcview" in my testing, works faster and better than V4L2 on Linux OS (is it because Unix is just better at it?), but "pwcview" uses the "pwc" driver and was ported to FreeBSD from Linux as well. I got nothing against Linux (I actually do, don't like how it all started compared to Unix), it's just that at the low level in software world for ported stuff, there are things that doesn't work well or isn't efficient on FreeBSD land, depending how much care the developer put into while porting to Unix systems.

I general avoid ported stuff and stick with native stuff when possible. From my understanding it makes no difference, since "sudo" also need it's executable UID set to root. However the only reason I see that is justifiable to use "sudo" is based on "security experience". However I plan to use complex custom cryptography implementation in my C/C++ code with the UID set to root which would make it much more difficult in hacking.

So for me, not using Linux's "sudo" and to get the job done naively floats my boat since it is easier but also I can make it more complex from hacking thanks to C/C++ cryptography and security libraries. The DVR FreeBSD system will also run fully offline so only pro hackers are needed to physically visit the system which is highly unlikely as compared to a system connected online 24/7(which is super silly, look at hackers easily hacking Ring and IP cameras). Also there seems to be more hackers who plays with the "sudo" stuff and would be more difficult for them if the DVR FreeBSD system does not contain any "sudo"(This is where doas comes into my vote, not to mention I do not see doas as foreign but rather a close native since OpenBSD is part of BSD's Unix which FreeBSD was also derived from).

Now lastly, I do use (sadly) PulseAudio (Linux stuff) so that I can then use professional GUI equalizer tools (Linux Stuff) to hear and utilize audio/sound in the most civil manner on FreeBSD 13.1. (Gotta give some credit to Mr. L for that ). Perhaps someday... these things will be fully implemented on FreeBSD using Unix's good old Open Sound System (OSS).

 

[msplsh]

1. There's no sense in being xenophobic on principle if you're having to compromise on the phobia to get what you want
2. Professional cryptographers do not recommend "rolling your own" custom cryptography
3. Being obscure does not mean you are secure (Neither does being popular )

I would avoid using a setuid binary as it paints a high value target on your binary.

Why not just add -B to the webcamd command, add it as a service in rc.local, and be done with it?

 

[mer]

Does this have to be done on user login?
If it's a "service" why not do it once at system start (sysinit stuff) and then user connects client of choice when logged in to view?
If it's a matter of permissions, why not create a simple devd conf file that sets permissions to allow any user to open the device?
This is done a lot of times for things like scanners and cameras so you don't have to be root to open them.
Example, this file in /usr/local/etc/devd/d610.conf allows a non root user to access a Nikon D610 when it's plugged in (darktable to pull images):
notify 100 { match "vendor" "0x04B0"; match "product" "0x0434"; action "chgrp wheel /dev/$cdev && chmod 660 /dev/$cdev"; };
Could you do something similar to the webcam?

 

[First_Law_of_Unix]

1. There's no sense in being xenophobic on principle if you're having to compromise on the phobia to get what you want
2. Professional cryptographers do not recommend "rolling your own" custom cryptography
3. Being obscure does not mean you are secure (Neither does being popular )

I would avoid using a setuid binary as it paints a high value target on your binary.

Why not just add -B to the webcamd command, add it as a service in rc.local, and be done with it?

Well my phobia is based on science due to the history of the beginnings of Unix and Linux in which I rather use Unix since end of the day, it gets the job done better than Linux. FreeBSD requires less headache to get the job done as compared to Linux, meaning by default I do not need to waste time in blindly reverse engineering software to know why and how it works since there are open documentation on FreeBSD which are better to understand than to Linux.

"Professional cryptographers do not recommend "rolling your own" custom cryptography" and this is the problem why things get hacked so easily, today's cryptography standards is all nonsense, specially for the web protocols, after reading all the popular cryptography standards I realized majority of them are useless. This is why smart companies roll their own cryptography concoction and your statement about being obscure is just your opinion, you do not have any scientific evidence that being so does not make one secure. This is why people who are recklessly not obscure gets hacked hence why they need to pay companies to protect their data. "Professional cryptographers" have no evidence scientifically that "rolling your own" is any safer than using the outdated easily hackable cryptography standards which billions of people use and which millions of hackers digging into and found handful of vulnerable bugs/loopholes to take their advantage.

Well I would rather use setuid binary since for my given situation, it gets the job done and it makes me less obscure since I know how and why my setuid binary works down to the bit as compared to me blindly trusting on sudo which I need to do some reverse engineering and asking many questions to exactly how and why sudo works (which I would like to avoid). I can easily tell when a hacker has infiltrated to my system when using setuid binary. I like to do things that are super simple and easy to understand so that I can make them advanced and secure.

Using the "-B" to the webcamd command is an excellent advice in which I will implement, Thank You.

Does this have to be done on user login?
If it's a "service" why not do it once at system start (sysinit stuff) and then user connects client of choice when logged in to view?
If it's a matter of permissions, why not create a simple devd conf file that sets permissions to allow any user to open the device?
This is done a lot of times for things like scanners and cameras so you don't have to be root to open them.
Example, this file in /usr/local/etc/devd/d610.conf allows a non root user to access a Nikon D610 when it's plugged in (darktable to pull images):
notify 100 { match "vendor" "0x04B0"; match "product" "0x0434"; action "chgrp wheel /dev/$cdev && chmod 660 /dev/$cdev"; };
Could you do something similar to the webcam?

Yes, it needs to be done during/after the login phase due to CPU efficiencies, power efficiencies and security. Only need to run things when they're most needed.

I have a complex setup of 6 CCTV analog cams connected to a HDMI to USB capture card, the capture card is seen as a webcam on FreeBSD. All of the webcams have identical serial number/hardware information. I know in Linux, the USB ports and every single internal and external peripheral hardware are not mapped to the physical PCB's labels as they should be (logically) and /dev/video0, video1, video2 always gets random USB ports after every restart. I hope FreeBSD does not do this.

However to follow best practices I need to setup devd rules to avoid cam's USB port links being randomized and still learning about it. However, what needs to be done is to create a six webcamd virtual loopback devices since each camera video feed needs to be shared among different softwares in real time simultaneously to OpenCV, FFMPEG and to FFPLAY.

Thank You for your example.

 

[msplsh]

"Professional cryptographers" have no evidence scientifically that "rolling your own" is any safer than using the outdated easily hackable cryptography standards

You obviously have your own dogmatic beliefs about a great many things I disagree about, but instead of picking all of them apart, I'll just pick one of them and supply a list of reasons why there is probably a difference, ignoring your requirement for "science" since that's not a measurable thing when "roll your own" is typically closed source.

Why shouldn't we roll our own?

Why shouldn't we create our own security schemes? I see a lot of questions around here about custom crypto and custom security mechanisms, especially around password hashing. With that in mind, I'm

security.stackexchange.com

 

[First_Law_of_Unix]

You obviously have your own dogmatic beliefs about a great many things I disagree about, but instead of picking all of them apart, I'll just pick one of them and supply a list of reasons why there is probably a difference, ignoring your requirement for "science" since that's not a measurable thing when "roll your own" is typically closed source.

Why shouldn't we roll our own?

Why shouldn't we create our own security schemes? I see a lot of questions around here about custom crypto and custom security mechanisms, especially around password hashing. With that in mind, I'm

security.stackexchange.com

Yes I have read endless of these sheep like "standardized" sayings to never "roll your own"... but look at Apple and Sony who rolls their own and many other companies.

No one was ever able to hack the PlayStation 3 (which it's OS used a fork of FreeBSD) at a conceivable scale which many users could easily play pirated games on PS3 when it was first released. Even till this day people are still trying to reverse engineer the PS3.

Good luck finding exploits with Apple's products (All of which are Unix stuff) custom cryptography and security implementations which they roll on their own.
This is why Andriod is so easy to hack, it's too basic and standardized when it comes to cryptography and security which the Andriod devs usually do not roll their own.

You'll never hear people talk about how rolling your own is better when you know what you're doing.

 

[SirDice]

No one was ever able to hack the PlayStation 3 (which it's OS used a fork of FreeBSD) at a conceivable scale which many users could easily play pirated games on PS3 when it was first released. Even till this day people are still trying to reverse engineer the PS3.

You know it's been broken a long time ago? Sure, it took a while but it was eventually cracked nonetheless.

View: https://www.youtube.com/watch?v=2yQCOso_4hc

 

[kpedersen]

Trust me, I wouldn't use it if there where native ways to do so. I need video loopback and so far to get the job done, I need to use v4l2loopback on FreeBSD.

If it helps, when I dealt with webcam in one of the last arcade cabinets, I just hacked a little at this code and made it into a library:

https://github.com/openbsd/src/blob/master/sys/dev/video.c

You can get it to read a stream from /dev/videoN quite easily and convert to raw bytes for a frame buffer.
The only thing you need on FreeBSD I believe is webcamd (and thus CUSE).

I found it much lighter than the full fat v4l and OpenCV approaches. Though it does still require a few v4l functions but can maybe avoid the v4l2loopback?

 

[msplsh]

No one was ever able to hack the PlayStation 3

You chose the best example ever for why not paying attention to standard practices is a bad idea.

PS3 hacked through poor cryptography implementation

A group of hackers named fail0verflow revealed in a presentation how they …

arstechnica.com

 

[First_Law_of_Unix]

You know it's been broken a long time ago? Sure, it took a while but it was eventually cracked nonetheless.

View: https://www.youtube.com/watch?v=2yQCOso_4hc

Well Sony is probably laughing at that video because it took a long time, so long that I ended up buying the PS4 on 2013 when it was first released and had no reason to mod the PS3 afterwards.
As same the PS4, it took even much longer time for it to be jail broken compared to the PS3, I read that it was jail broken maybe a year or two ago, but now there is the PS5 (also based on FreeBSD) released on 2020 and have plans to buy the PS5 without putting effort for jailbreaking the PS4. I'm that type of person who doesn't enjoy playing legacy games, since its not good for multiplayer and missing out on latest gaming tech experience .

So it seems Sony did very well, prevented hackers and reverse engineers for piracy for both PS3 and PS4 time era back-to-back, all the game studios got their projected revenues for both the PS3 and PS4 without loss, lets see how long PS5 lasts before PS6 releases. I read that Sony specifically choose the FreeBSD OS because of it's BSD license which it prevented hackers to break their security system in finding loopholes easily, it granted Sony to fully custom design and heavily modify the FreeBSD OS and drivers so that nothing about it's softwares were ever forced to be open and is fully owned by Sony. Linux GNU licence requires the software to be open source and hackers can peak into it.

If it helps, when I dealt with webcam in one of the last arcade cabinets, I just hacked a little at this code and made it into a library:

https://github.com/openbsd/src/blob/master/sys/dev/video.c

You can get it to read a stream from /dev/videoN quite easily and convert to raw bytes for a frame buffer.
The only thing you need on FreeBSD I believe is webcamd (and thus CUSE).

I found it much lighter than the full fat v4l and OpenCV approaches. Though it does still require a few v4l functions but can maybe avoid the v4l2loopback?

Thank You, will look into this.

You chose the best example ever for why not paying attention to standard practices is a bad idea.

PS3 hacked through poor cryptography implementation

A group of hackers named fail0verflow revealed in a presentation how they …

arstechnica.com

I read many of these a decade ago when I had my PS3, end of the day I was still not able to get a working modded PS3 (just like millions of other PS3 users) before the PS4 arrived.
Just because they found one little flaw doesn't mean the PS3 is fully cracked, Sony's custom security implementation is way more complex than that. I bet Sony quickly found out and easily patched it, no big deal.

Also, Sony brought a huge scary lawsuit against that hacker you mentioned on your link, guess who won end of the day(more like years)? (You guessed it, SONY):

Sony Computer Entertainment America, Inc. v. Hotz - Wikipedia

en.wikipedia.org

I mean when it comes to hardware, its no brainier that rolling on your own security is the way to to go.
Just look at: Apple, Samsung, Dell, Sony, HP, Lenovo, LG, Cisco, Canon, Nikon, US military and etc.
All of these companies need to make secure products and prevent hacking/reverse engineering and they all roll on their own security concoction implementations and is not meant to be public knowledge.

Lets talk about more about software techs.
Is it a coincidence that "Amazon" rolls on their own security implementation, like holy moly, Amazon is something like no other, they fully custom design everything from scratch down to the transistor for their businesses. Same goes for google, they fully custom design everything from scratch and roll on their own security protocols. I do not remember a time when Amazon had such terrible data breaches as compared to the ones who rolls on their own depending on how things got hacked, I wonder why...

Not rolling on you own is the reason why I read endless of articles how so many tech companies (who doesn't roll on their own) gets the worst data breaches. Here is a list of the most worst hacks when numbers comes into play, numbers in terms for both overall loss of money and users info being affected:

The 35 Most Notorious Hacks History | Indusface Blog

What were the most notorious hacks in history? They’re subject to debate, but we bring you 27 of them, which would be strong candidates for the title.

www.indusface.com

Keep a note, watch the news, I bet that when you read about a tech company being data breached badly, do some investigation, did this company custom designed everything on their own including the security implementation... I bet, most likely not.

Yahoo got the worst of them all on 2013, they simply didn't roll on their own and guess what happened? 1 billion accounts leaked. (names, DOB, contact details, and passwords.) If Yahoo was smart about things and rolled on their own, the damage would obviously wouldn't be that great. The web devs had absolutely no idea what they were doing and didn't even realized that the hackers were literally sleeping on their databases.

I mean reading these horror stories just ring's my common sense to never trust no one, never trust anyone's security implementation saying that it will keep you safe without knowing exactly how and why it keep you safe. From my experience, people who doesn't know anything about computer engineering and knows only about computer science will always say never roll on your own and with the facts I just presented just makes me to always roll on my own. Today's popular modern "Computer Science" syllabus is all a joke, you'll have a dev who doesn't know the difference between a bit and a byte, what is a transistor and how it was created, what is Unix and why it's important, never heard about C programming, even worst never did any kind of proper C++ programming or embedded projects, only knows how to program "fluently" on python and was told to never roll on your own and just copy and paste the open sourced security protocols, welcome to modern CS.

The only time I will roll on my own is when the security requirements are not important, the only time I'll roll on my own is when security is super important.

 

[drhowarddrfine]

Note: I have not read through this whole thread.

There have been a number of articles online about the insecurity of using other people's code. Specifically node/npm and changes made by someone without warning.

When I started my web dev company, 19 years ago, we got royally screwed by Microsoft when they made a change to .NET. We were just getting started and that change set us back by many months and cost us a lot of money, almost putting us under. It's why we switched to FreeBSD.

We stuck to the basics. We built everything ourselves when we could. Whenever there was trouble, it was always other people's programs and code. Rolling our own, we were in control and a lot can be said for that.

 

[mer]

Some things make sense to roll your own, others not so much.
A lot of computer security is based on cryptographic algorithms. I hope we can all agree on that.
Two of the biggest issues around crypto are:
A strong algorithm, meaning very hard/impossible to crack without the appropriate keys. A tradeoff is performance because the strongest algorithm that reduces performance by 50% is not very useful in the real world.
Implementation of the algorithm. You can have a perfect implementation of a bad algorithm or an imperfect implementation of the strongest algorithm. Either way you are vulnerable.

Devising strong crypto algorithms is a specialized talent, much like writing compliers. Not very many people have the ability to do either.
Implementing them correctly is typically more of a general skill, but one that needs to be done carefully.

That's why a lot of people roll their own around publically available algorithms and implementations (GPG/PGP, OpenSSL, etc). Yes there can still be problems with the publically available code but more people using can aid in finding problems. Note I said "can" not "does".

 

[msplsh]

who won end of the day

It was settled, not won.

If you think that the "one little flaw" from Sony rolling their own crypto implementation and not following the standard practices did not completely break down the PS3 security by exposing the root key, then you must not have have read much about it or don't understand what went on. Either way, I'm sure what's going to protect your system is obscurity and lack of being an interesting target rather than whatever you plan on doing, so have fun with that. You know several different ways to do what you need to do with the video, with varying degrees of "correctness" to them and I'm sure it actually doesn't matter which one you choose.

 

[First_Law_of_Unix]

It was settled, not won.

I hope you knew about the context with my statement, Sony won with regards protecting their game studio partners since no one was able to get a modded PS3 to start playing pirated games on it before the PS4 was released. This means SONY and their game studio partners got every single dime of profits thanks to no one able to get a modded PS3, this means Sony and their partners won with their revenue projections against piracy. Also the case being settled obviously benefits only Sony. This makes them win so hard that they released the PS4 and the PS3 was still not modded yet. By the time people got their hands on the PS4, no one cared anymore to spend money or take the time effort to mod the PS3 to play legacy games. Sony also doesn't greatly care either and focusing on hackers trying to hack on their main flagship console PS4.

But to make my point here, why Sony (and like every top earning (also smart) companies in the world) rolls on their own, I'll use quantitative information:
Sony wanted to avoid piracy for the PS3 due to the huge overlord piracy experience done to the PSP portable consoles(that stuff was way too easy to hack), so they rolled on their own and launched it on 2006... hackers/reverse engineers were so dumbfounded it took them a ridiculous 5 years (yes, five full complete years) to figure out to find the first ever hard loophole on 2011. If that genius didn't have such a big mouth, Sony wouldn't know to file a lawsuit against with but lets not forget that it takes time to start making the hack work for the mass public to use for easy jail break, it would take another 1-2 years for the first stable PS3 jailbreak to occur.
But lets say hypothetically, that genius anonymously released a stable jailbreak hack super quickly (using magic) on the second quarter of 2012, this means hackers still lost the battle, it's too late, since Sony released the PS4 on 2013, no one cares about playing games on PS3 anymore, millions of people were saving up cash for the PS4 on 2012 and couldn't wait until it was released on 2013.
So conclusion, hypothetically (if that genius stayed as a law abiding anonymous citizen) if the hack was released on 2012 (thanks to magic) instead of 2014(which is more ideal), Sony partners got 6 years worth of their projected revenue since the first PS3 was released on 2006, got every dime of it right before they dropped the holy PS4 on 2013, all thanks to Sony's immense effort in rolling on their own.

Sony was so successful rolling on their own for the PS3 that they did the same thing with the PS4. Jesus, hackers/reverse engineers probably bashed their heads against wall for failing so hard to find any hard hacks and implementations that it took them an immense ridiculous 7 years to release the first stable jailbreak on 2020 for the public to use. But PS5 was released on 2020, so it's too late. Sony and their partners once again, won again, thanks to rolling on their own super hard. Now before you start posting exploits that was found on starting on 2014 for the PS4, they are irrelevant in terms of rolling on your own, because it's about the amount of users who are able to apply the hack to their PS4s which in return harms Sony and their partners. Those bucket filled PS4 exploits were only for the few wise guys and not for the millions of PS4 users who only knows how to jailbreak iPhones. All of these exploits were easily avoided by forcing PS4 users to update the PS4 if they ever wished to play online multiplayer games. Thats why the first easy jailbreak took so long until it was released on 2020 and people are still trying to find a stable jailbreak for the latest PS4 firmware even till 2021:

Reddit - Dive into anything

www.reddit.com

If Sony never rolled on their own for their PlayStaion linage, they would've been bankrupted since their largest revenue only comes from their gaming business:

Sony sales by business segments 2011-2023 | Statista

Revenue generated from Sony’s game and network services amounted to 28.5 billion U.S.

www.statista.com

Another article explains how PlayStation kept Sony going:

PS4 Helps Push Profits For Sony... No They're Not Going Bankrupt

Over the years things have settled (in the games division) and the company is now posting profits thanks in large part to the PlayStation division.

www.cinemablend.com

So I have given proof in scientific manner using quantitative information stated above which can't be disproven, when it comes to money and preventing hackers ruining your business and partners, best believe to roll on your own (Mr. SONY doesn't need to convince you, so doesn't Steve Job and his right hand man Tim Cook, it's no wonder why Apple is currently today in the world with the most revenue, since all they do best at is rolling on their own.).

There have been a number of articles online about the insecurity of using other people's code. Specifically node/npm and changes made by someone without warning.

When I started my web dev company, 19 years ago, we got royally screwed by Microsoft when they made a change to .NET. We were just getting started and that change set us back by many months and cost us a lot of money, almost putting us under. It's why we switched to FreeBSD.

We stuck to the basics. We built everything ourselves when we could. Whenever there was trouble, it was always other people's programs and code. Rolling our own, we were in control and a lot can be said for that.

This is the reason why I support rolling on my own, its best for those who wants full control of their products and services to avoid reliance from 3rd parties.

Some things make sense to roll your own, others not so much.
A lot of computer security is based on cryptographic algorithms. I hope we can all agree on that.
Two of the biggest issues around crypto are:
A strong algorithm, meaning very hard/impossible to crack without the appropriate keys. A tradeoff is performance because the strongest algorithm that reduces performance by 50% is not very useful in the real world.
Implementation of the algorithm. You can have a perfect implementation of a bad algorithm or an imperfect implementation of the strongest algorithm. Either way you are vulnerable.

Devising strong crypto algorithms is a specialized talent, much like writing compliers. Not very many people have the ability to do either.
Implementing them correctly is typically more of a general skill, but one that needs to be done carefully.

That's why a lot of people roll their own around publically available algorithms and implementations (GPG/PGP, OpenSSL, etc). Yes there can still be problems with the publically available code but more people using can aid in finding problems. Note I said "can" not "does".

There is a balance which companies use which is specifically tailored for them, they use both advanced implementations of hardware/software and different levels of complexity of cryptographic algorithms (depending how much security is needed) to provide an economic wise of security and performance for their customers. This can only be done rolling on your own since all companies in the world are different with required objectives all of which with a common goal is to prevent hackers/reverse engineers as the main priority.

That is true that, that not many people have the ability to implement/parse crypto algorithms directly, I blame this due to not being introduced for it. The main issue is that today's CS syllabus is terrible and doesn't dig down to the low level stuff like compilers and introduction to cryptography theory and programming, they made this into a separate major called "IT cyber security" where they do delve into the upper level of cryptography implementation but end of the day all the real mathematical cryptography theory and low level programming is left for only specialized individuals who understands complex math and low level programming to implement new crypto algorithm security protocols which they might open source or start a business with. Thankfully for me at least, I have the Compiler "Dragon" book in my reading list along with C/C++ cryptography books.

I support in rolling on your own using with the help of opensource crypto implementations, this is what many companies do, making your own crypto algorithm from dead scratch is just a big no-no unless you have a PhD background in math specializing cryptography. Trust no one and not knowing how and why the crypto implementation keeps your business safe is a one way ticket to disaster in data breach. This is why companies pay professionals and closed sourced cyber securities for their businesses and custom design everything themselves.