I'm not asking for "good service", just a product that is actually functional. In that regard, one reason for low shipping cost is because the domestic ground shipping services in China (to N America) are ridiculously cheap compared to the reverse. Yeah you may have to wait a month or two for the product to arrive (literally by ship), but you should get it eventually.
Now in cases where it's simply a cheap product and that's more or less what I expect, that's fine. When it's supposedly a *new* product and shows up obviously used, is supposedly legit but is obviously counterfeit, or simply isn't even the product I ordered then yes, I do expect that I shouldn't be out-of-pocket for it. If they want it back then they can pay me the cost of shipping. In some cases it's not even that the shipping to me was free, but that I'm not willing to pay again 20% of the item value to return it
Anything else is supporting a fraudulent business model. I don't entirely agree with Amazon is doing, as basically you're trading potential unscrupulous sellers for unscrupulous buyers, but there needs to be a balance here.
A good example of this is eBay's supposed anti-counterfeit program. I ordered a box set of DVD's that weren't even available locally except through very pricey specialty stores in a different city. They arrived and despite a nice box and decent silkscreening, were obviously bootleg (scanlines where they were recorded from a TV/VCR, horrible fansubs). Now the item still cost nearly $100, shipping it back in any meaningful way was about $20, and eBay wanted me to somehow find a "expert" who would write a written attestation that the item was fake (apparently sending a video or screenshot wasn't enough). I should have just been able to straight get my cash back on that, but instead the seller got my cash and all I got for my $$$ was something I could have downloaded online and burned myself.
Because it's a valid user on the system and there's no reason to create an artificial restriction against it. The restriction was created because originally the system f***ed up and allowed it to continue as the privileged user. I'm honestly not sure why #user was a restriction in the first place, if it was valid on the system, as a logical flow is
* Valid user on system, proceed to running as the lesser privileged account. Not a valid user, die with an error
And it apparently already does check if the user exists, so realistically adding cruft just obfuscates the issue. Most of the issues around lefthand-numerical users are due to confusion in lazy checking of a UID versus username, in the case of code that supports either.
Not supporting leading digits is not a security issue (though screwing up the implementation of such previously definitely was), but by properly validating against system-valid users it would be a non-issue regardless.
No, there isn't any distribution that I'm aware of that uses left-hand users by default. But the false premise in this is that systems will only use code that by default comes with the distribution by default, as opposed to having code which works with users the distribution allows.
Last I read (and perhaps that has changed, but I've seen nothing to indicate thus in either the github thread nor the CVE) the "fix" was to have it error out on the username should it start with a digit, even though it was a valid user on the system. Still, killing it is DEFINITELY better than the original behavior of running as root (or most simply failing to adequately drop privileges).
Now the argument has been given (github) that privilege-dropping could be done by the application rather than systemD or that the unit files should never start with a numeric in order to be os-portable. Simply validating the existence of the user would seem to make it plenty portable, as if left-side-numeric usernames are not permitted they should not otherwise exist. POSIX (which about as close to a standard as you'll get) also seems like the standard allows for usernames starting with a numeric:
3.437 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2008, the value is composed of characters from the portable filename character set. The character should not be used as the first character of a portable user name.
It specifically calls out usage of a hyphen as the start of a username (likely to avoid conflicts with a flag), but nowhere limits an initial numerical character that I can see.
Now don't get me wrong, there are some things I do like about systemD - in particular the ability to create nested unit files to build derivative/custom configs without breaking the main script - but it's not just the error but the *REACTION* to the error that's sometimes quite maddening. Maybe it's just that team's way of doing things, and certainly Poettering isn't a stranger to controversial modules/changes (though I quite like Pulseaudio these days), but for F*** sakes at least own up rather than hands-up.
The first comment from P on this was essentially "oh, well this isn't a valid username dumbass" rather than "shit, our code allows stealthy privilege escalation, let's fix it".
There are a ton of things that are extremely cheap to make in decent quality, but have massive markup in local stores (or, alternately not available). $5 does tend to be the low-end but return shipping can still often equal 20-50%+ the cost of an item of higher value.
No, it behaves the exact same as any other machine running the same OS Distro as me, with versions ranging back several years. Thus far distributions I have tested this includes: Ubuntu/Mint (Current versions as I don't have any older ones kicking around) CentOS 7 RedHat 6/7
Oh, and who does Lennart Poettering work for, well it's REDHAT, and yeah their OS happily allows me to create a username with a leading number. In fact, the only Linux OS I've been able to test that doesn't without some extra flags has thus far been (recent versions of) Debian.
But - barring some massive cranial-rectal inversion - you already knew what I was talking about behavior of useradd in various Distros and not specific binary versions, so you just want to be a prick about that. That's fine:-)
This seems to be a big issue with overseas sellers - I point to China because they're the most common - and shipping. My $5-20 item may come with free shipping, but when it arrives and is broken or turns out to be a fake piece of crap, the return cost may end up being more than the value of the item (especially if I want it tracked and within a reasonable time period).
Around here most wires are often clipped to the clips. In some cases a coaxial cable gives you enough oomph to brute-force it through and pop all the clips, but often it's not quite enough.
No, MY useradd is the same as all the other people who use one of the MOST POPULAR fucking Linux distributions out there. It's absolutely not stupid to work towards supporting such, unless you're a systemdickhead....
It is usually RECOMMENDED to only use usernames that begin with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes
Emphasis mine, RECOMMENDED is NOT insists. I recommend you learn how to read, and insist you remove your head from your ass.
Yes, but it doesn't give accurate percentages of those affected. Near 100% in those donating their body to science, but that might account for only a small percentage of those involved in the sport (also, what about other sports with high-speed impact, such as hockey)
I use both Windows and Linux systems. First things first I say this: it doesn't matter how strong your OS is if you don't take care of your apps. Over the last several years, a consistent source of vulnerabilities has been either Flash or Java, with issues for either coming out pretty much monthly if not weekly. With that also comes a trickle-down to some other common applications such as jBoss, Tomcat, etc. *Thankfully* we're seeing a decline in flash-based UI's, but I still see some vendors using them even with more recent products.
Not back to Windows VS Linux. There is of course the argument that Linux really is the kernel, but for sake of sanity I'll include the common userland stuff in there because, frankly, a kernel is not useful without something to run on it. So let's say your shit has a vulnerability, whether it be a kernel issue or a buffer overflow in Apache/Samba. In windows-land, you are unable to test this except for black-box style. You're also generally at the mercy of the OS vendor to provide a timely fix, and not to include something bad in their regular patches. Sometimes these patches are also pretty light on the details so as to not provide hackers info.
So what does this mean in general: Windows systems are generally at the mercy of MS to keep secure, and frankly some of their recent shenanigans (win10 auto/nagging upgrade patch, telemetry patch) has people on edge about accepting patches. End result: unpatched, unaudited systems which are vulnerable
BUT, to assume that this means Linux is Fort Knox is foolish. There's the regular stream of application patches, kernel vulnerabilities come out regularly, and baseline libs also run into issues. The part I like is that if my application has an issue, then I can either a) Wait for the distro vendor to supply a patched version b) Possibly replace the binary with a fixed version from a third party c) Patch and/or recompile myself
There's also the issue of *what* you need to patch. While many people use the distro-supplied kernels, it is pretty easy to roll your own (start with the distro options, uncheck boxes, compile). That allows you to remove stuff you don't need, which tweaks performance *AND* remove stuff that might actually lead to a vulnerability.
The end result is that while Windows and Linux both have security issues, a smart sysadmin has more tools at his/her disposal to secure a Linux distro. However, keep in mind that in windows-land one often also has more options to obtain professional/paid third-party advisement or support in securing systems.
Newer windows are definitely better than their predecessors, at least in part due to the former versions have more of a local-privilege focussed security model. It's arguable that Linux is getting worse in some ways (systemD). I guess we'll see where we are a few years from now
IIRC, initially they did advertise as "waterproof" but later change that to "strongly resistant" because people were taking the things diving etc.
But yeah, they scoffed at rain, puddles, and toilet drops so long as all the pieces were in place. It was also one the the earlier devices to support inductive charging (require a special backplate but it was pinned for it).
The the S6 came out. Unibody style design (no removable battery), but also not as resistant to water as the S5. Seemed like a step back to me.
P.S. you can get new clips (I assume you mean for the USB port) on eBay for cheap, and they're easy to replace.
Imagine if Samsung had made a removable battery in these. Solve the battery issue and you don't need to recall an entire line of phones worldwide, just recall and ship new batteries.
It would also have given better optics: "see, it's not our phone but the battery produced by X that was defective"
Well, when it comes to phones the one I have works great, costs less than the comparable big-brands, and has removable storage. The latter was one of the main decisions that I bought it instead of a Samsung (that and it wasn't SIM-locked) If it had a version with a removable battery, I'd have paid more for that.
Realistically, these options don't cost that must to incorporate into a well-designed device, and can even save the company money (e.g. if the Note7 defects were all in the battery, they could have done a battery recall/swap instead of a full device recall).
And yet the GS5 had strong water-resistance (puddles fine) plus a removable battery and SDXC slot, all it really takes is a proper gasket.
Hell, they could make the back screw-on, which would hold it tight but still allow me to pop it open when I need to swap something out. I used to really like the way the old iDevices were put together in this regard as they basically clipped/hinged at the top and then there was a latch at the bottom into which two tiny screws held the phone thing nicely (and tightly) in place.
Also, 20 years ago or even 10 IMAP was not nearly so common as it is now. Around a decade ago the first iPhone came out, and arguably smartphones were one of the major things that started the push for IMAP versus POP3.
Prior to that, I'd be surprised if he was getting his mail by IMAP and not a POP3 account with Outlook Express, Thunderbird, or something else similar.
If you're worried about that, then relying on your ISP to hold mail records is probably not the best idea. I know tons who have lost mail or accounts, and they don't really have any guarantees that they'll hold the data indefinitely.
If you want the old mail, connect with POP3, such it down into a box you own, and archive it.
You can even move mail between ISP's by setting up two IMAP accounts and copying from one to another (or POP3 to IMAP).
Not starting the service is the appropriate response in this case, I wasn't arguing that, but rather that it's not just homebrewed unit files that are at risk. A system unit file could also cause privilege escalation if there's issues with the underlying user.
I'd rather have my webserver crap out on startup than run with root privileges.
You don't need a home-written unit file, just some other issue that makes a user unavailable on a system (deleted, inaccessible to the underlying authentication mechanism, etc).
For example, a tomcat/apache/etc host where the tomcat or www-data user is missing.
Most shops I know that are paying for RHEL support contracts, not for the software. That gives them somebody to call if issues come up or there's a critical bug to fix, as well as access to the KB's etc.
I don't know that SystemD changes this much. If anything, it's hurting RedHat's reputation.
There was a recent case where the Canadian court dismissed the arbitration and jurisdiction portions of an agreement between a Canadian user and Facebook. This means that not only will it not be going through an "arbitrator", but it will be heard in Canadian courts under Canadian law (which is as it should be if you're offering the service to Canadian customers).
On the other hand, we also had a case where the courts decided they had jurisdiction over content shown/posted in other countries. That's less cool to me for fairly obvious reasons.:-(
Slashdot Mirror
I'm not asking for "good service", just a product that is actually functional.
In that regard, one reason for low shipping cost is because the domestic ground shipping services in China (to N America) are ridiculously cheap compared to the reverse. Yeah you may have to wait a month or two for the product to arrive (literally by ship), but you should get it eventually.
Now in cases where it's simply a cheap product and that's more or less what I expect, that's fine. When it's supposedly a *new* product and shows up obviously used, is supposedly legit but is obviously counterfeit, or simply isn't even the product I ordered then yes, I do expect that I shouldn't be out-of-pocket for it. If they want it back then they can pay me the cost of shipping. In some cases it's not even that the shipping to me was free, but that I'm not willing to pay again 20% of the item value to return it
Anything else is supporting a fraudulent business model. I don't entirely agree with Amazon is doing, as basically you're trading potential unscrupulous sellers for unscrupulous buyers, but there needs to be a balance here.
A good example of this is eBay's supposed anti-counterfeit program. I ordered a box set of DVD's that weren't even available locally except through very pricey specialty stores in a different city. They arrived and despite a nice box and decent silkscreening, were obviously bootleg (scanlines where they were recorded from a TV/VCR, horrible fansubs). Now the item still cost nearly $100, shipping it back in any meaningful way was about $20, and eBay wanted me to somehow find a "expert" who would write a written attestation that the item was fake (apparently sending a video or screenshot wasn't enough). I should have just been able to straight get my cash back on that, but instead the seller got my cash and all I got for my $$$ was something I could have downloaded online and burned myself.
Because it's a valid user on the system and there's no reason to create an artificial restriction against it. The restriction was created because originally the system f***ed up and allowed it to continue as the privileged user. I'm honestly not sure why #user was a restriction in the first place, if it was valid on the system, as a logical flow is
* Valid user on system, proceed to running as the lesser privileged account. Not a valid user, die with an error
And it apparently already does check if the user exists, so realistically adding cruft just obfuscates the issue. Most of the issues around lefthand-numerical users are due to confusion in lazy checking of a UID versus username, in the case of code that supports either.
Not supporting leading digits is not a security issue (though screwing up the implementation of such previously definitely was), but by properly validating against system-valid users it would be a non-issue regardless.
No, there isn't any distribution that I'm aware of that uses left-hand users by default. But the false premise in this is that systems will only use code that by default comes with the distribution by default, as opposed to having code which works with users the distribution allows.
Last I read (and perhaps that has changed, but I've seen nothing to indicate thus in either the github thread nor the CVE) the "fix" was to have it error out on the username should it start with a digit, even though it was a valid user on the system. Still, killing it is DEFINITELY better than the original behavior of running as root (or most simply failing to adequately drop privileges).
Now the argument has been given (github) that privilege-dropping could be done by the application rather than systemD or that the unit files should never start with a numeric in order to be os-portable. Simply validating the existence of the user would seem to make it plenty portable, as if left-side-numeric usernames are not permitted they should not otherwise exist. POSIX (which about as close to a standard as you'll get) also seems like the standard allows for usernames starting with a numeric:
3.437 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2008, the value is composed of characters from the portable filename character set. The character should not be used as the first character of a portable user name.
It specifically calls out usage of a hyphen as the start of a username (likely to avoid conflicts with a flag), but nowhere limits an initial numerical character that I can see.
Now don't get me wrong, there are some things I do like about systemD - in particular the ability to create nested unit files to build derivative/custom configs without breaking the main script - but it's not just the error but the *REACTION* to the error that's sometimes quite maddening. Maybe it's just that team's way of doing things, and certainly Poettering isn't a stranger to controversial modules/changes (though I quite like Pulseaudio these days), but for F*** sakes at least own up rather than hands-up.
The first comment from P on this was essentially "oh, well this isn't a valid username dumbass" rather than "shit, our code allows stealthy privilege escalation, let's fix it".
Ah yes, the old "why fix this security/integrity issue, it's not that it's likely to happen" defense :-)
There are a ton of things that are extremely cheap to make in decent quality, but have massive markup in local stores (or, alternately not available). $5 does tend to be the low-end but return shipping can still often equal 20-50%+ the cost of an item of higher value.
No, it behaves the exact same as any other machine running the same OS Distro as me, with versions ranging back several years. Thus far distributions I have tested this includes:
Ubuntu/Mint (Current versions as I don't have any older ones kicking around)
CentOS 7
RedHat 6/7
Oh, and who does Lennart Poettering work for, well it's REDHAT, and yeah their OS happily allows me to create a username with a leading number. In fact, the only Linux OS I've been able to test that doesn't without some extra flags has thus far been (recent versions of) Debian.
But - barring some massive cranial-rectal inversion - you already knew what I was talking about behavior of useradd in various Distros and not specific binary versions, so you just want to be a prick about that. That's fine :-)
This seems to be a big issue with overseas sellers - I point to China because they're the most common - and shipping. My $5-20 item may come with free shipping, but when it arrives and is broken or turns out to be a fake piece of crap, the return cost may end up being more than the value of the item (especially if I want it tracked and within a reasonable time period).
Around here most wires are often clipped to the clips. In some cases a coaxial cable gives you enough oomph to brute-force it through and pop all the clips, but often it's not quite enough.
No, MY useradd is the same as all the other people who use one of the MOST POPULAR fucking Linux distributions out there. It's absolutely not stupid to work towards supporting such, unless you're a systemdickhead....
REALLY?
linux ~ # useradd 0intelligence
linux ~ #
Uh, nope, that works fine.
Man page:
It is usually RECOMMENDED to only use usernames that begin with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes
Emphasis mine, RECOMMENDED is NOT insists.
I recommend you learn how to read, and insist you remove your head from your ass.
Yes, but it doesn't give accurate percentages of those affected.
Near 100% in those donating their body to science, but that might account for only a small percentage of those involved in the sport (also, what about other sports with high-speed impact, such as hockey)
My 2c on this.
I use both Windows and Linux systems. First things first I say this: it doesn't matter how strong your OS is if you don't take care of your apps. Over the last several years, a consistent source of vulnerabilities has been either Flash or Java, with issues for either coming out pretty much monthly if not weekly. With that also comes a trickle-down to some other common applications such as jBoss, Tomcat, etc.
*Thankfully* we're seeing a decline in flash-based UI's, but I still see some vendors using them even with more recent products.
Not back to Windows VS Linux. There is of course the argument that Linux really is the kernel, but for sake of sanity I'll include the common userland stuff in there because, frankly, a kernel is not useful without something to run on it. So let's say your shit has a vulnerability, whether it be a kernel issue or a buffer overflow in Apache/Samba.
In windows-land, you are unable to test this except for black-box style. You're also generally at the mercy of the OS vendor to provide a timely fix, and not to include something bad in their regular patches. Sometimes these patches are also pretty light on the details so as to not provide hackers info.
So what does this mean in general: Windows systems are generally at the mercy of MS to keep secure, and frankly some of their recent shenanigans (win10 auto/nagging upgrade patch, telemetry patch) has people on edge about accepting patches. End result: unpatched, unaudited systems which are vulnerable
BUT, to assume that this means Linux is Fort Knox is foolish. There's the regular stream of application patches, kernel vulnerabilities come out regularly, and baseline libs also run into issues. The part I like is that if my application has an issue, then I can either
a) Wait for the distro vendor to supply a patched version
b) Possibly replace the binary with a fixed version from a third party
c) Patch and/or recompile myself
There's also the issue of *what* you need to patch. While many people use the distro-supplied kernels, it is pretty easy to roll your own (start with the distro options, uncheck boxes, compile). That allows you to remove stuff you don't need, which tweaks performance *AND* remove stuff that might actually lead to a vulnerability.
The end result is that while Windows and Linux both have security issues, a smart sysadmin has more tools at his/her disposal to secure a Linux distro. However, keep in mind that in windows-land one often also has more options to obtain professional/paid third-party advisement or support in securing systems.
Newer windows are definitely better than their predecessors, at least in part due to the former versions have more of a local-privilege focussed security model. It's arguable that Linux is getting worse in some ways (systemD). I guess we'll see where we are a few years from now
IIRC, initially they did advertise as "waterproof" but later change that to "strongly resistant" because people were taking the things diving etc.
But yeah, they scoffed at rain, puddles, and toilet drops so long as all the pieces were in place. It was also one the the earlier devices to support inductive charging (require a special backplate but it was pinned for it).
The the S6 came out. Unibody style design (no removable battery), but also not as resistant to water as the S5. Seemed like a step back to me.
P.S. you can get new clips (I assume you mean for the USB port) on eBay for cheap, and they're easy to replace.
Ah, I misunderstood the issue and thus stand corrected:
Unit file has invalid/missing user: breaks and won't start
Unit file has valid user (that it doesn't like): runs as root instead
Still kinda crappy but at least not as dangerous as the first scenario which I had mistakenly imagined might occur.
Thanks for correcting me.
It can even save the company money.
Imagine if Samsung had made a removable battery in these. Solve the battery issue and you don't need to recall an entire line of phones worldwide, just recall and ship new batteries.
It would also have given better optics: "see, it's not our phone but the battery produced by X that was defective"
Well, when it comes to phones the one I have works great, costs less than the comparable big-brands, and has removable storage. The latter was one of the main decisions that I bought it instead of a Samsung (that and it wasn't SIM-locked) If it had a version with a removable battery, I'd have paid more for that.
Realistically, these options don't cost that must to incorporate into a well-designed device, and can even save the company money (e.g. if the Note7 defects were all in the battery, they could have done a battery recall/swap instead of a full device recall).
And yet the GS5 had strong water-resistance (puddles fine) plus a removable battery and SDXC slot, all it really takes is a proper gasket.
Hell, they could make the back screw-on, which would hold it tight but still allow me to pop it open when I need to swap something out. I used to really like the way the old iDevices were put together in this regard as they basically clipped/hinged at the top and then there was a latch at the bottom into which two tiny screws held the phone thing nicely (and tightly) in place.
What's the parent company? Is there perhaps something going on with the stock? Maybe a market expansion planned?
I'd be less worried about the legion and more about the lawyers in the wrongful-dismissal case that will follow.
Also, 20 years ago or even 10 IMAP was not nearly so common as it is now. Around a decade ago the first iPhone came out, and arguably smartphones were one of the major things that started the push for IMAP versus POP3.
Prior to that, I'd be surprised if he was getting his mail by IMAP and not a POP3 account with Outlook Express, Thunderbird, or something else similar.
If you're worried about that, then relying on your ISP to hold mail records is probably not the best idea. I know tons who have lost mail or accounts, and they don't really have any guarantees that they'll hold the data indefinitely.
If you want the old mail, connect with POP3, such it down into a box you own, and archive it.
You can even move mail between ISP's by setting up two IMAP accounts and copying from one to another (or POP3 to IMAP).
Not starting the service is the appropriate response in this case, I wasn't arguing that, but rather that it's not just homebrewed unit files that are at risk. A system unit file could also cause privilege escalation if there's issues with the underlying user.
I'd rather have my webserver crap out on startup than run with root privileges.
You don't need a home-written unit file, just some other issue that makes a user unavailable on a system (deleted, inaccessible to the underlying authentication mechanism, etc).
For example, a tomcat/apache/etc host where the tomcat or www-data user is missing.
Most shops I know that are paying for RHEL support contracts, not for the software. That gives them somebody to call if issues come up or there's a critical bug to fix, as well as access to the KB's etc.
I don't know that SystemD changes this much. If anything, it's hurting RedHat's reputation.
There was a recent case where the Canadian court dismissed the arbitration and jurisdiction portions of an agreement between a Canadian user and Facebook. This means that not only will it not be going through an "arbitrator", but it will be heard in Canadian courts under Canadian law (which is as it should be if you're offering the service to Canadian customers).
On the other hand, we also had a case where the courts decided they had jurisdiction over content shown/posted in other countries. That's less cool to me for fairly obvious reasons. :-(