Restricted shell to change the password
 

Hello,
How can I do a shell that just allow the user to change his password?...JUST change the password, so deny anything else.
Thanks a lot!

You would change the shell so it just goes to whatever you want
example of entry in /etc/passwd user named testing:
testing:x:6834:6834::/home/testing:/usr/bin/passwd
What happens when you log in:
[blinky@Spork ~]--> su - testing
Password:
Changing password for user testing.
Changing password for testing
(current) UNIX password:
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[blinky@Spork ~]-->

THANKS A LOT, is exactly what I wanted...

If there are no login restrictions and if there is no authentication before getting login/passwd, then you create a possibility for people to try bruteforcing passwd.

So that's not how you would only allow the user to only change the password? :confused: Or are you talking enabling services like telnet, ssh, ftp, etc? I would agree that anytime you open up access to a box there is a security risk... but a box locked in a vault without power might be secure but not very usable...

So that's not how you would only allow the user to only change the password?
No, that's *not* what I'm saying, the procedure itself isn't flawed AFAIK. Btw, I forgot to mention "secured connection"...

Using access restrictions (where possible), a separate passwd database and a SSL-wrapped tool is IMO the only real option. Using a separate database a daemon doesn't need access to the passwd/shadow files and the SSL-wrapped tool should make the connection somewhat trustworthy.


but a box locked in a vault without power might be secure but not very usable
That is a typical reaction, and I wonder why you made it (care to elaborate?).
IMHO risks should be either calculated (and then accompanied by restrictions making sure *you* remain in control), or the result of flawed reasoning (like saying "ease of use" is way more important).

I agree risks need to be calculated... I've just had too many Audit people come in and regurgitate the latest security thing to me. Like for example a windows flaw on a Unix system or having security so tight you have to authenticate 3 different times to find out what the cafeteria is having for lunch. :rolleyes: (don't laugh I've seen it) Now I'm not saying that audit is bad and that security isn't important. I'm just saying security needs to fit the situation.
Some people may say it's good to change your root password every 6 weeks, the next thing you know management says if every 6 weeks is good every 3 must be better, next thing you know you're walking by desks and people have Root password: fuzzysl1pp3rs on a post-it note on the monitor.
I think everyone needs to ask themselves how much security they need and everyone will come up with a different answer. What is the data worth to you? What steps are you taking to preserve it? Is there something you can do to make things more secure? Are you willing to take the risk?

I think everyone needs to ask themselves how much security they need and everyone will come up with a different answer.
I know what you're heading for, but unfortunately it doesn't work that way and you know it. Before you react, remind yourself this *is* a newbie-facing site, which means we're at the forefront of the security spearhead as far as I'm concerned.

Newbies in general don't take interest in securing their bright, shiny new toy with the go-faster stripes and the blinky icon lights, and not enough people point out it should be. Besides that "securing" is too often perceived as taking away (newfound) freedom, tedious, obscure The ability to make educated guesses about security issues requires rudimentary interest and knowledge, and that is not something we can expect (or get shown proof of) most of the time. Hell, most of the time a (possible) breach of compromise is presented something like "eeewww, my system is goin, like, all weird on me...", and preferably posted where I don't usually look (five pages deep in another forum).

So to me this means: raise awareness now, get in the discipline to perform basic hardening and maintenance routines, try to spark interest where we can and *then* pray they find the time and guts to actually *read* some basic docs before it's too late.

I'm not saying I'm bitter about the situation being as it is, but until someone shows a faint interest in doing the math wrt risks, that is how we need to "sell" the goods for now.

Use sudo:

I was going to write exactly how to do it but this is just what you need.

Link
http://www.linux4biz.net/articles/sudo.html

The system should still prompt for a login password before passing them off to /usr/sbin/passwd for a shell. At least that's what happened when I tested it on one of my systems. It's not an ideal solution, but it should work for non-high risk settings.

The system should still prompt for a login password before passing them off to /usr/sbin/passwd for a shell. At least that's what happened when I tested it on one of my systems. It's not an ideal solution, but it should work for non-high risk settings.

And what would you see as "low risk settings" usage?
And does that setup guard against brute forcing accounts?
Delving a bit deeper, what are good examples of situations where someone would need this b0rken kind of functionality?
I'm thinking of people who have an account on abox for accessing just one service, like an FTP stash, or a POP3 account. IMHO these type of acocunts shouldn't be served out of passwd/shadow, but a separate database.

I did say that is was not ideal, and it should be suitable for a trusted group of friends. I wouldn't use this in any sort of production environment. Personally, I don't even like giving people real user accounts unless they need access to the file system.

It's only I'm just stumped by the lack of checking requirements before getting ready to answer in this thread, I won't exclude myself there.

//In my eyes this is more of a "meta" issue wrt solving security questions, and Blinker_Fluid already touched on the subject telling about prev experiences, and I can see how that can influence someone's attitude towards posting a possible solution for a "problem" a certain way, and how leaving out considerations/reasoning why/how a certain answer was given (esp. w/o enough background info) will set up the user with only an answer, and not info no build his/her own decision on. Guess we all have to try harder to approach (solving) these kind of security related issues not as a "one answer only" thing, but more of an if, elif (decision) tree...