On 04/14/2017 01:58 PM, Carlos E. R. wrote:

But not for "systemctl hibernate"

There's only so much we can do to protect you from yourself. Maybe manually set red backgrounds on each window that is not local. Maybe never get root on those ssh boxen, and always rely on sudo and make sure each has a different root password. -- After all is said and done, more is said than done.

On April 14, 2017 7:29:50 PM PDT, "Carlos E. R." wrote:

On 2017-04-15 02:51, John Andersen wrote:

...

On 04/14/2017 01:58 PM, Carlos E. R. wrote:

...

But not for "systemctl hibernate"

There's only so much we can do to protect you from yourself.

Maybe manually set red backgrounds on each window that is not local. Maybe never get root on those ssh boxen, and always rely on sudo and make sure each has a different root password.

The color thing might be a trick. Not red, perhaps dark blue. Not sudo, because the plain user can also hibernate, without using sudo.

I thought you had to be at the console or be root to hibernate or suspend? If not, that's a security issue. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 14, 2017 7:38:49 PM PDT, "Carlos E. R." wrote:

On 2017-04-15 04:33, John Andersen wrote:

...

On April 14, 2017 7:29:50 PM PDT, "Carlos E. R." <> wrote:

...

...

Not sudo, because the plain user can also hibernate, without using sudo.

I thought you had to be at the console or be root to hibernate or suspend?

If not, that's a security issue.

You can, if you are the sole user of the computer. If there are more users, there is an automatic inhibit. Via systemctl you can ignore them, but it asks for root password.

Consider that a user can suspend just by closing the lid.

Exactly my point. You have to be at the console. There's no defense against someone at the console. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 14, 2017 8:28:39 PM PDT, Anton Aylward wrote:

On 14/04/17 10:48 PM, John Andersen wrote:

...

Exactly my point. You have to be at the console. There's no defense against someone at the console.

I would rather say that there's no defence against someone with root password at the console.

Everything that's been mentioned on this thread except for that is configurable: the action arising from the switch that seems the laptop lid closing, for example.

Edit /etc/UPower/UPower.conf and add IgnoreLid=true See also logind.conf(5)

More is configurable with SUDOers, the settings in /etc/pam.d, and of course policykit controls. If you are running SElinux there's more still.

But root at the console, well that's it. You're the system GOD. Even if the system has been set up to stop you doing something "accidentally" you can edit that control out of existence.

See that power cord hanging out the back of the machine? You got that in your hand you don't need no stinkin root. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 14, 2017 8:42:22 PM PDT, Anton Aylward wrote:

On 14/04/17 11:31 PM, John Andersen wrote:

...

See that power cord hanging out the back of the machine?

You got that in your hand you don't need no stinkin root.

I recall at one client I had the only working machine when the building power went out. apart from the mainframes in the raised floor IT centre, that was.

I was the only one running a laptop.

I keep telling you guys ..

Context is Everything

The batteries come out of those things, and holding down the power switch still shuts them down. There's no defense against the guy with his mits on your machine. Thankfully Carlos is looking for a defense against himself. Not so much somebody sitting at the keyboard. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 14/04/17 11:53 PM, John Andersen wrote:

...

Thankfully Carlos is looking for a defense against himself.

OBTW, John, I subscribe to the list to there is no need to send a duplicate to me as well :-)

----- Actually, Anton, in this situation, I'll agree that John isn't following suggested mail protocol, since you have a 'Reply-To: opensuse@opensuse.org' in your email headers. However, posting to other lists with that reply-to string in your headers is, *ahem*, bad form! (having been bitten by that more than once). Can't you have a mail-post-compose/ pre-delivery script that looks at the "To" header, and if it is to a list, then add an appropriate reply-to field?). If you really need a script to do it, I can likely whip up one in perl in short order, though you'd have to "install" it into your outgoing email chain... p.s. John -- shame on you! ;-)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 15/04/17 10:03 PM, L A Walsh wrote:

Anton Aylward wrote:

...

On 14/04/17 11:53 PM, John Andersen wrote:

...

Thankfully Carlos is looking for a defense against himself.

OBTW, John, I subscribe to the list to there is no need to send a duplicate to me as well :-)

----- Actually, Anton, in this situation, I'll agree that John isn't following suggested mail protocol, since you have a 'Reply-To: opensuse@opensuse.org' in your email headers.

Yes, it was you who suggested I do that to address this very issue!

However, posting to other lists with that reply-to string in your headers is, *ahem*, bad form! (having been bitten by that more than once).

This account is *ONLY openSUSE.

Can't you have a mail-post-compose/ pre-delivery script that looks at the "To" header, and if it is to a list, then add an appropriate reply-to field?).

If I'm rely to a message on this this list at all, which is a result of pressing wither the "reply-to" or "reply-to-list" in Thunderbird while reading a message on this list, then it *IS* a list. This account is UNIQUE to openSUSE list. So it is only adding the 'Reply-To: opensuse@opensuse.org' for replies to this list. That is set up for the account in the Thunderbird config on a per account basis for this and only this account. So it does what you suggest without the need for an external script.

If you really need a script to do it, I can likely whip up one in perl in short order, though you'd have to "install" it into your outgoing email chain...

That's a very kind offer. I'm a lot more than 20 years from being proficient in Perl :-( However I'm not aware of how I possibly _could_ install it in the chain with Thunderbird. This, like all my accounts, reads directly from my ISP via Thunderbird's IMAP mechanism at that unique mailbox and writes directly to the corresponding SMTP for that account. So the "chain", as far as I can see in internal to Thunderbird. On the occasions that I use my phone or tablet to handle email I use K-9 or K-@ and there is a similar unique per account set-up. I note that John uses his phone and K-9. Perhaps this is a shortcoming of K-9, I don't know. Perhaps he's being optimistic and using a 'reply-all' in the absence of a 'reply-to-list'. I'll have to go look-see. I'm aware that some people read their email via a spam filter proxy. My ISP runs a spam processor - I think it is SpamAssassin from the way the GUI lets me configure settings - and it does an excellent job. I suspect that there might be a SMTP proxy as well. That's nice, but why should I pay for that just to insert a "reply-to" header on one of the MANY accounts that I use? Not least of all when Thunderbird is doing it anyway. It may be that there's a plug-in for Thunderbird that let's you hook in to the outgoing SMTP chain. My google-fu is OK but that skill doesn't seem to work well with Mozilla's internal search arrangement. I haven't seen one and I suspect it wouldn't be that perl-friendly. I'm aware that I *could* run a SMTP proxy such as Postfix on my own machine and have that set up as the mail proxy for Thunderbird for this one account. I seems a lot of effort though. It is also not a solution for my phone/tablet. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 16/04/17 10:06 AM, L A Walsh wrote:

Anton Aylward wrote:

...

[...]

---

Um... Your ISP's IMAP and SMTP are not internal to Tbird... FWIW, I arrange my incoming email @ my ISP to come down in 1 IMAP folder polled every minute w/fetchmail.

I'm well aware of this, Linda, and I'm well aware of what you go on to describe. It's in the class of "Yes it used to be, but I changed all that". if it was just one or two accounts as it used to be, or if this was a situation where my ISP supports only POP, as was once the case, then yes. But part of the reason for not downloading, for using IMAP, for using an ISP that is willing to run spam-detection for me, is that I have a bandwidth cap. Many months, that's to buqqering around with upgrades and zypper-overloads I run over my cap and the penalty for excess with the local cable provider is ... nasty. So a motivation for using IMAP is not to download with fetchmail, not to process with Postfix and local SpamAssassin, not to run though Procmail. That in turn, and the fact that my domain supporting ISP allows for lots-and-lots of email accounts, makes it simpler to use one-account per list or subject. And yes, I have a number of "main, personal" accounts for different levels of contacts, yes I have an account for each technical list I'm on, yes I have a number of accounts for differing types of aka-ortho-nearly "business" like podcasts, conference invitations and such like. I can get my ISP to burden the input filtering and have Thunderbird do additional cleanup, the kind of thing that you might do with Procmail, sorting and tagging and prioritizing. But only by envelope. I don't download the message. IMAP is nice.

[...] I actually tried procmail, but it wasn't stable enough yet, so I went to perl (perl4 at the time) to write a filter -- it distributes the email into one of 50-70 active folders that are served to me via "Dovecot".

I've got about 20 "accounts" and probably two or three times that number of folders. The extra folders are handled by Thunderbird and its filters. I do run Dovecot, but its there to serve up the "archives". Many of the Thunderbird filters move critical to folders there rather than under the ISP/IMAP hierarchy. For example, all the accounts have Thunderbird saving "sent" and "archive" locqally so as to reduce network loasd. As I say, exceeding the cap is EXPENSBIVE.

...

I'm aware that some people read their email via a spam filter proxy. My ISP runs a spam processor - I think it is SpamAssassin from the way the GUI lets me configure settings - and it does an excellent job. I suspect that there might be a SMTP proxy as well. That's nice, but why should I pay for that just to insert a "reply-to" header on one of the MANY accounts that I use? Not least of all when Thunderbird is doing it anyway.

----- Once email is queued on and sent from your machine, you don't need to pay for an SMTP proxy from your ISP -- you run your own on your own home network. I try to avoid paying others for computer services I should be able to run myself on a linux-based home PC. I run spamassassin as part of the incoming filtering process.

As I said "Yes it used to be, but I changed all that". I pay my ISP and my ISP runs these services.

...

I'm aware that I *could* run a SMTP proxy such as Postfix on my own machine and have that set up as the mail proxy for Thunderbird for this one account. It seems a lot of effort though. It is also not a solution for my phone/tablet.

---- Yeah... I don't have one of those. Just my home systems, so I don't have to worry about such for now. When I was working at an employer site, I'd setup a VPN into my home network and still read my email from my home server -- even work email, since I had already had the sorting infrastructure setup there.

That's in the proverbial "snows of yesteryear" for me also. But in turn some employers decided that such channels were a security risk. Hmm, there's the case of ... some guy who set up a channel like that to his home computer and was eventually charged with hacking ... I forget who that was. So using my phone to "call Home", well actually to call my ISP, not using any of the company's resources (not even their electricity as I have a battery-pack and usually carry a spare battery anyway) avoids such matters. Well not entirely: I could take a photograph of a screen ... Some paranoid establishments might ask to check in phones and tablets just as they used to ask to check in cameras or other recording equipment. But in this day and age when people take notes on their tablet rather than on paper ... and lets not even discuss the matter of the camera built in to my false eye or other jamesbond-ian devices. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-17 00:31, L A Walsh wrote:

Anton Aylward wrote:

...

But part of the reason for not downloading, for using IMAP, for using an ISP that is willing to run spam-detection for me, is that I have a bandwidth cap.

---- Major *ouch*. That's a reason why I don't have a portable phone -- on top of paying 50-75 bucks a month just for the privilege of having a "dial tone" (and network access), they want to charge extra for actually *using it* (duh!), and then more for traffic above caps.

So, you are telling me that my Spanish and expensive telephone system is actually better than yours? :-P Includes land line, TV, internet, and mobile pone. Land line at 300 Mbps (symmetrical), no cap. Mobile has a 3 GB cap. All phone call free.

Unfortunately, the US is moving away from having a middle class and going back to having a wealthy class, and the rest of us.

That's happening here, too. Or has already happened. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-04-15 05:53, John Andersen wrote:

Thankfully Carlos is looking for a defense against himself. Not so much somebody sitting at the keyboard.

Of course, I'm not looking for a full deterrent, just something that reminds me to think twice. The ideal would be those commands asking for a confirmation. Or a file that if present disables those commands with a message. Surely I'm not the first one that has powered down a computer by mistake ;-) Like the kid pushing the Big Red Button -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Carlos E. R. wrote:

On 2017-04-14 22:11, Dave Howorth wrote:

...

On Fri, 14 Apr 2017 19:45:28 +0200 (CEST) "Carlos E. R." wrote:

...

Do we have a method so that halt, reboot, suspend, hibernate operations are disabled? Requiring a secondary confirmation or removal of the inhibit?

Ah, yes. That could work, at least for halt or reboot. I will do it, thanks.

But not for "systemctl hibernate"

--- Neither for "kill -9 1". That's why only 'root' can 'normally' do those things (w/the idea that they'd be responsible)... But in regards to having "training wheels" on commands, please don't encourage the Gnannies -- they only dumb down utils and remove functionality. There are many examples, but due to gnu slavishly following the posix nannies (who took orders from the BSD folks "protecting the children"), "rm" can no longer be used to safely remove all of a directory's contents (w/o removing the directory). It used to be you could use "rm --one-file-system -fr ." or "rm -fr --one-file-system "DIRNAME/." to remove everything under (or in) the directory you were in or in "DIRNAME" (respectively). Now, you need to use 'find' to do something along the lines of: 'find . -xdev -depth |xargs rm -fr' :-( ! (find has a "-delete" option, but I don't know that it's "posix" approved). For a tree like: Ishtar:/tmp/foo1> tree . . ├── a ├── b ├── d ├── mnt │ └── file └── mnt_file 2 directories, 4 files one might think to use "rm *" (indeed some have suggested this). 12345678901234567890123456789012345678901234567890123456789012345678901234567890 But turning on hidden files, inode & devices: Ishtar:/tmp/foo1> tree -a --inodes --device . . ├── [8550811 2082] .c │ ├── [ 5126 2082] .a │ └── [8550812 2082] b ├── [17400567 2082] .e ├── [17319254 2082] a ├── [17400566 2082] b ├── [17400568 2082] d ├── [23013870 42] mnt │ └── [23014625 42] file └── [23014625 42] mnt_file 5 directories, 5 files ------------- - Note: "hidden members": .c, .c/.a .c/b and .e and note: mnt_file, mnt/, & mnt/file are on a separate device from the root of the dir... So this is needed for safety now:

find . -xdev -depth -delete

vs. rm (an uncastrated version)

rm -frx .

Which leaves: Ishtar:/tmp/foo1> tree -x --inodes --device . . ├── [23013870 42] mnt └── [23014625 42] mnt_file 1 directory, 1 file I used to use things like: cd /mnt/foo1 && rm -fr . to be extra safe about my deleting everything under a directory (where I knew there were no mounted file sysytems). Little chance of mistyping and deleting something I didn't want deleted -- no slashes in my "rm" with it protected/dependent on the 'cd'. Also nanny work: defaulting "ls" to quoting filenames. Work to remove use of ENV vars and disallow setting default behaviors for your local commands (like having grep skip binary files or devices) is under way. :-? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/14/2017 03:52 PM, Carlos E. R. wrote:

I thought of that, but it needs to be able to inhibit for months. Ie, ignore completely the request to reboot or whatever.

If you enable the inhibiting process as a service on boot, it should block until you tell it to stop manually, either by stopping the service or just killing the process. I haven't investigated it further, but it looks like it could be as simple as starting a process that sets such a lock (I don't know, just set a read that blocks waiting for some input forever, and tag it as an inhibiting process) then it should take no cpu sleeping until you kill it, but effectively prevents reboot or shutdown until you do. I'll have to play with it in my spare time :) -- David C. Rankin, J.D.,P.E.

On 2017-04-15 14:24, Rüdiger Meier wrote:

On 04/14/2017 07:45 PM, Carlos E. R. wrote:

...

Do we have a method so that halt, reboot, suspend, hibernate operations are disabled? Requiring a secondary confirmation or removal of the inhibit?

Scenario: ssh to server. I can accidentally type the wrong command to the wrong session and thus disable the server. If I'm local restoring is easy, but not if remote.

Happened already once (I was local).

IMO it makes no sense to protect you from yourself by adding a "secondary confirmation" dialog.

It would suffice ;-)

Instead you could either

1. add a way to start the server via remote (iAMT, IPMI, WoL and/or most system independent powerline networking adaptors).

Only by rigging a motor to push the button, LOL! :-) Or phoning some one to please push the button.

2. configure your server that it *always* reboots (via BIOS, or call "rtcwake" from a shutdown script). And disable suspend/hilbernate somehow.

Ah, that "somehow" is the problem ;-) I think I will create my own hibernate script and get used to call that one instead of the "systemctl hibernate" call, something that I wanted to do already for other reasons. I'm not aiming to make a fully failsafe server. Just a reminder when trying to halt the computer will be enough for now. I think I will do that alias trick. PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games Can't be a script for this one, though. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)