Which is why the peer-review process includes more than a single reviewer. Now we don't know what happened to the paper you reviewed but thus far it sounds like the process worked as intended. Perr review is not there to be 100 pct safe, it's just there to keep some safety margins. The real test comes once it's published and the scientific community at large can read it.
Actually you have right now 2 LTS releases, 1 non-LTS release and one non-LTS alpha available from Ubuntu. And since Ubuntu is based on Debian they don't need to accept new packages because they get them once they enter Debian anyway.
And btw those popups you get is due to apport, I don't think it's used outside Ubuntu which is why you don't see them on other distributions when apps crash there.
No it does not work like that. The main archive is supported by the Ubuntu core team, i.e the employed people. And tje rest is supported by the cummunity managers, like how 100Ã of the packages in Debian are supported.
Or 'editions' as they apparantly are called now since Windows 10. Don't know if SP still are a thing on their server line though.
But you are correct and more people should understand this, people running say Windows Server X are not running the initial release anymore.
Tell that to your distribution because it's them that changed your default. Yes the journald default is this but since it's configurable the distribution choose to not change it to match their old behaviour.
Well technically it could have registered as a trigger event on the BT stack so it gets unfrozen when the BT stack sees data intended for the app. Of course it could then also start the app...
Well that is the 'problem' with an open court system where evidence cannot be presented with a simple 'he is guily, trust us'. Still haven't stopped criminals from doing stupid stuff since the dawn of time anyways.
True, but to be honest that Samba exploit required the user to already have write access to the share. Still bad, but not as bad as this SMBv1 exploit.
Because there have to be an active attack that does this for you in order for it to be full escalation, that you start a service as whatever user by mistake is not full escalation unless that mistake was due to some one tricking you into doing it.
Well if some one steals your identity number you will probably change your position. If I have access to your identity number and have criminal intent then there is no stop to the things that I can do in your name without you ever stopping me. If/when the police catches me you will have a breathing room until I give that identity number to some one else or I get out of jail and start to use it again.
Everything you do in the Swedish society, either with the government, with banks or with private companies can be done in your name if I have acess to your identity number and since it's used in so many places the number have enter that strange state of being both almost public and private at the same time. That we have not experienced the same amount of identity theft as say the US yet have to do with other factors, not that our system is more secure, on the contrary.
Well it probably haven't been misused like this before. Also notaries are not common in Sweden since we don't use our courts as often as say Americans.
I would also guess that the court does not see this as a problem since it can be reversed. That you personally get lots of trouble are not their concern...
There are only 3 qualifications:
#1 That it is signed. The signature is not validated since the court doesn't have peoples signatures. The signature is so you can contest the application later, which happened here.
#2 That the fee is paid. For a personal bancrupcy the fee is zero.
#3 That the filing person is under the specific courts jurisdiction.
All 3 where qualified. These rules sounds like this have not been misused until today, and they will most likely be changed.
This all happens due to our usage of a national id in Sweden that is given to all citizens, which is used almost everywhere, is easily guessed and cannot be changed. It's your birthdate as YYMMDD-ABCD where ABC is your birthplace with an incrementor to support more than one birth per day and place and this number is even for boys and uneven for girls and D is a simple checksum.
Well glad I don't have to use such shitty software. I have yet to see an upgrade of RHEL or CentOS that breaks the software that we create and support for our customers.
The state of the bug is shown near the top. LP closed the bug, saying it's not-a-bug, and then locked the discussion, because he can't stand to have people point out that he's full of crap.
And now systemd will no longer run a unit with an invalid name: https://github.com/systemd/sys... , so as I assumed there where further non-public discussions that eventually led to this bug being solved.
Also if I recall it led to a security issue with Ubuntu some years ago.
I think it was the other way around, since Ubuntu used Dash instead of Bash for these scripts they avoided the Shellshock exploit (unless Dash was affeected too of course).
But yeah, when they switched over I had some head scratching moments when scripts worked perfectly in the terminal but not on cron or during init.
Don't know, better yet but doesn't any of my machines show any of this corruption if it's caused by journald? And I run some servers with several millions of rows of logs per server per day, but not a single corruption.
Yes there are other tools that don't have that limitation and you could write your own tools. But that is besides the point because I'm not talking from the "I hack on my own system" point of view, I'm talking about creating init scripts meant for distribution and that will work on all systems. When you do that you can not hope that the end user have daemontools installed or some other tool that does this for you. This is where systemd (and upstart before it) helps because it offers all this functionality and more as a base.
You need an expect script if you plan to use su in a init script so that you can supply the password to it, your "su 0day -c/usr/bin/daemon" would just hang the the entire boot sequence waiting for interactive input. The permissions is that your "0day" user must have execute rights on/usr/bin/ which it does not need if you use User= in systemd. Your 0day user also needs to have a shell, somehting that the User= in systemd doesn't need.
And even with something like daemontools (which I have used extensively back when I wrote sysv scripts for Gentoo) the daemon runs as a different user but not the rest of the sysv script, which btw is one of the ways that the MySQL sysv script was hacked last year.
Apparently, "as far as you know" isn't very far at all. You probably should stop talking about topics that you obviously know next to nothing about.
So show me a single sysv script shipped with any distribution that uses SU in order to run a daemon as a different user, a single one.
Ouch that sounds really bad. Wonder what that vendor or your was up to, they must have been doing something really nasty for an update like that to break in such a way.
Slashdot Mirror
Which is why the peer-review process includes more than a single reviewer. Now we don't know what happened to the paper you reviewed but thus far it sounds like the process worked as intended. Perr review is not there to be 100 pct safe, it's just there to keep some safety margins. The real test comes once it's published and the scientific community at large can read it.
Just a stupid AC who doesn't understand that old does not mean unmaintained.
Actually you have right now 2 LTS releases, 1 non-LTS release and one non-LTS alpha available from Ubuntu. And since Ubuntu is based on Debian they don't need to accept new packages because they get them once they enter Debian anyway. And btw those popups you get is due to apport, I don't think it's used outside Ubuntu which is why you don't see them on other distributions when apps crash there.
No it does not work like that. The main archive is supported by the Ubuntu core team, i.e the employed people. And tje rest is supported by the cummunity managers, like how 100Ã of the packages in Debian are supported.
Or 'editions' as they apparantly are called now since Windows 10. Don't know if SP still are a thing on their server line though. But you are correct and more people should understand this, people running say Windows Server X are not running the initial release anymore.
Tell that to your distribution because it's them that changed your default. Yes the journald default is this but since it's configurable the distribution choose to not change it to match their old behaviour.
Since you executed the script it actually doesn't sound like systemd was involved at all.
Well technically it could have registered as a trigger event on the BT stack so it gets unfrozen when the BT stack sees data intended for the app. Of course it could then also start the app...
But then they are also not frozen.
Well that is the 'problem' with an open court system where evidence cannot be presented with a simple 'he is guily, trust us'. Still haven't stopped criminals from doing stupid stuff since the dawn of time anyways.
So all the millions of Linux users cannot run a single app they need. Are you sure?
True, but to be honest that Samba exploit required the user to already have write access to the share. Still bad, but not as bad as this SMBv1 exploit.
Because there have to be an active attack that does this for you in order for it to be full escalation, that you start a service as whatever user by mistake is not full escalation unless that mistake was due to some one tricking you into doing it.
Well if some one steals your identity number you will probably change your position. If I have access to your identity number and have criminal intent then there is no stop to the things that I can do in your name without you ever stopping me. If/when the police catches me you will have a breathing room until I give that identity number to some one else or I get out of jail and start to use it again.
Everything you do in the Swedish society, either with the government, with banks or with private companies can be done in your name if I have acess to your identity number and since it's used in so many places the number have enter that strange state of being both almost public and private at the same time. That we have not experienced the same amount of identity theft as say the US yet have to do with other factors, not that our system is more secure, on the contrary.
I think they slap that name on when they have aquired the rights to the series in contrast to just having a time limited license deal.
Well it probably haven't been misused like this before. Also notaries are not common in Sweden since we don't use our courts as often as say Americans. I would also guess that the court does not see this as a problem since it can be reversed. That you personally get lots of trouble are not their concern...
There are only 3 qualifications: #1 That it is signed. The signature is not validated since the court doesn't have peoples signatures. The signature is so you can contest the application later, which happened here. #2 That the fee is paid. For a personal bancrupcy the fee is zero. #3 That the filing person is under the specific courts jurisdiction. All 3 where qualified. These rules sounds like this have not been misused until today, and they will most likely be changed. This all happens due to our usage of a national id in Sweden that is given to all citizens, which is used almost everywhere, is easily guessed and cannot be changed. It's your birthdate as YYMMDD-ABCD where ABC is your birthplace with an incrementor to support more than one birth per day and place and this number is even for boys and uneven for girls and D is a simple checksum.
Well glad I don't have to use such shitty software. I have yet to see an upgrade of RHEL or CentOS that breaks the software that we create and support for our customers.
The state of the bug is shown near the top. LP closed the bug, saying it's not-a-bug, and then locked the discussion, because he can't stand to have people point out that he's full of crap.
And now systemd will no longer run a unit with an invalid name: https://github.com/systemd/sys... , so as I assumed there where further non-public discussions that eventually led to this bug being solved.
Also if I recall it led to a security issue with Ubuntu some years ago.
I think it was the other way around, since Ubuntu used Dash instead of Bash for these scripts they avoided the Shellshock exploit (unless Dash was affeected too of course).
But yeah, when they switched over I had some head scratching moments when scripts worked perfectly in the terminal but not on cron or during init.
Don't know, better yet but doesn't any of my machines show any of this corruption if it's caused by journald? And I run some servers with several millions of rows of logs per server per day, but not a single corruption.
So your claims of "full escalation" was "mild criticism"? Still no one have presented a single credible way to exploit this.
So now the sysv script that I distribute to people borks if they don't have runit installed?
Yes there are other tools that don't have that limitation and you could write your own tools. But that is besides the point because I'm not talking from the "I hack on my own system" point of view, I'm talking about creating init scripts meant for distribution and that will work on all systems. When you do that you can not hope that the end user have daemontools installed or some other tool that does this for you. This is where systemd (and upstart before it) helps because it offers all this functionality and more as a base.
You need an expect script if you plan to use su in a init script so that you can supply the password to it, your "su 0day -c /usr/bin/daemon" would just hang the the entire boot sequence waiting for interactive input. The permissions is that your "0day" user must have execute rights on /usr/bin/ which it does not need if you use User= in systemd. Your 0day user also needs to have a shell, somehting that the User= in systemd doesn't need.
And even with something like daemontools (which I have used extensively back when I wrote sysv scripts for Gentoo) the daemon runs as a different user but not the rest of the sysv script, which btw is one of the ways that the MySQL sysv script was hacked last year.
Apparently, "as far as you know" isn't very far at all. You probably should stop talking about topics that you obviously know next to nothing about.
So show me a single sysv script shipped with any distribution that uses SU in order to run a daemon as a different user, a single one.
Ouch that sounds really bad. Wonder what that vendor or your was up to, they must have been doing something really nasty for an update like that to break in such a way.