How to require password when resuming after swsusp
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Definitely don't run it from root account. A better way is, for example, to configure sudo so that you (or your preferred user(s)) can run the command without password asked (or with the user's password asked, if you like - better this way). For this install sudo, configure /etc/sudoers file (add the preferred user along with the command; see the example lines there for syntax) and that should be it. Somewhere I saw that users had to be in the 'sudo' group before it worked, so if it's not working before that, you can try adding the users there.
After it's configured, the users can run
to run command with root privileges (possibly with sudo asking for the user's password). Note: don't let anybody run sudo, a shell or similar with sudo (read: think carefully what you let them run, and restrict it as tightly as possible) because that will result in a root login with no restrictions.
Another possibility is to set uid for the executable, so it's run with root's privileges.
Have you tried what it does if you run
swsusp ; xscreensaver
This is just off the top of my head, but would it then run swsusp, and when it returns, next run xscreensaver (in case you ran that from X) to lock the screen? Change xscreensaver to whatever you want to lock the screen with, or possibly "logout" or "exit"..not sure if it works, but try. Creating a desktop icon for that should be easy, at least using sudo or setuid (prefer sudo, without password if it's needed..).
sudo is very helpful. I set it up to allow all users to access swsusp without password. That works well. I also love the default insults if you make a mistake. Using swsusp ; xscreensaver suspends the machine, but when it resumes, it does not go into screensaver, but prompts for settings. xscreensaver-command -activate is the go. That disables the screen immediately.
So, thank you very much, the problem is solved. I've also bios disabled all other boots except for hard disk, and password protected bios and grub. Is there any way in left? If not, I should put it all in a script?
Using swsusp ; xscreensaver suspends the machine, but when it resumes, it does not go into screensaver, but prompts for settings. xscreensaver-command -activate is the go. That disables the screen immediately.
Sorry, my mistake - didn't remember 'xscreensaver' merely runs the settings dialog. Well, good you sorted it out. You can make the script all right, there are very probably some holes left (if there was a sure way to set up everything in a secure way, there would already be a howto for it) but the greatest ones are BIOS and bootloader passwords (most people don't bother setting them). You should probably read Slackbook (visit www.slackware.org) which has some good information, and if you're interested in security overall, get (loan, they're not too cheap) some books about securing a UNIX system, or about computer security in general. The path is endless, but for example here at LQ are some nice documents (howtos, threads, ..) about making a good start for securing it.
You could also add something more to the command, knowing that "a ; b" means "execute b after a has finished", "c && d" means "execute d if c finishes successfully" and that "e || f" means "execute f only if e exits with errors". So, if for some reason xscreensaver couldn't run, the system would probably leave a shell open unless you did something to it. This is probably minor, but you can always play around and see how it goes, for example with a line like this
just as an example, the starting part is the same you already tried, but in the end "sudo reboot" would be run if xscreensaver exited abnormally (with return value different from zero). Something like that. Rebooting is not necessarily the best idea, but you probably got what I meant.
Got it. I've also dropped /usr/bin/xscreensaver -no-splash into my autostart folder, so that whenever the machine is rebooted, it's there right away, without going into the setup dialogues. Otherwise xscreensaver-command does nothing. (just in case anyone else is trying to do the same thing).
I'll check out those other options, which just have to be useful in all sorts of other ways too.
I thought it was a laptop with sensitive information. In this case a full encryption would be the only way for 100% security, as resetting a bios password is possible or physically cloning a harddisk.
Rereading your post and considering the context I guess its tightened enough (although you never know with kids nowadays .
I didn't see you had locked the bios so it's not trivial. Sorry, my mistake..
Is it a problem if he forces a reboot? Because encrypting won't help, he can still poweroff-poweron during resume or even after. On next reboot he would be on the login window but I guess that's ok... ?
It's tight enough. At the outset, it was just clearly dangerous to leave a shell open with root privileges, so my last post was more like a bit of natural interest.
At that age, I know that as soon as I saw the machine had been secured, I'd have been giving it a go.
Generally, I do want users to be able to boot as well as suspend from and resume to their own accounts, so it's just inconvenient if someone forces a reboot after I've suspended. I could lose open files, say. So I don't want to tempt that.
Say one user powers on the machine after another user put it into suspend to disk, is there a way to get them into their own account without destroying the original session(s), which should remain locked?
Turns out there are a couple of little problems using xscreensaver for this purpose, mainly because the script should work whether the process is already running or not, and because users can kill, restart and modify settings on xscreensaver.
So, I think it gets a bit complicated that way. I found another way, xlock, which just locks the screen until password is provided. Has many options.
The entire script I'm using just now is:
sudo /sbin/swsusp ; xlock +allowroot
With permissions on the script (owner = root) set to 755, accessed from (KDE) desktop icon. I have not yet thought of a way to get around this, so if anyone can think of one, please let me know.