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!
Notices
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.
Good luck. The OP was pointed there before, but still doesn't seem to get that unless these 'admins' (who apparently can't be trusted not to reboot a live server without good cause, or run fsck on a mounted volume) are restricted to an incredibly small set of commands (and are locked out of the server room), that there is no real solution for their "management official reasons" request.
They don't seem to realize that:
If they can get into the server room, they can log in as root on a console and do whatever they want
If they can get into the server room, they can UNPLUG the server physically and reboot it (negating the first "official reason" of "not allowed to reboot")
If they can reboot the server they can also boot it to single-user mode and fsck anything (negating the second "official reason" of "not allowed to fsck")
That if they have ANY sort of sudo rights past a few commands, they can get in as root and do anything (negating BOTH points)
That if they have ANY sort of sudo rights past a few commands, they can reset system time to avoid the "official restrictions" on hours those things can be done (negating points 1 and 2 as before)
..which brings things full-circle to what cynwolf said, and I agree with: it's all about trust. If these 'admins' are too stupid to know not to do these things, or just don't care, then they do not need to be admins and/or have admin rights, it's that simple. But the OP says that we someone 'don't understand' these issues.
Absolutely correct. In a secure domain the first level of protection is physical access. Once that is granted, many bets are off; however the point here is "granted" versus "compromised".
Part of granting is also giving trust to those persons. If they are not worthy of trust, then they should not be granted access and privileges.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.