Shell confusion

[quote=426871:@Tim Jones]Why on Earth would anyone warn against sudo? It’s much saner than straight up “su” and can be controlled very carefully via the /etc/sudoers and /etc/sudoers.d components down to specific apps/tools for specific users. If you have users who are afraid of sudo, they should either get a good book on Unix system administration or probably contact that South Florida real estate company …

My response to that post is “rm is simply a Unix tool, but can be highly abused if used improperly …” or “mv is simply a Unix tool, but can be highly abused if used improperly…”. Anything on a Unix-based system can be abused. Using sudo is the least probable issue for problems.

Plus, with my code above, how would your user know WHAT you are using? All of that would be compiled into your app and completely hidden from the users. Your app would completely hide the sudo side of things in much the same manner that gksu does. If they are afraid of sudo, they should be just as afraid of gksu and friends. Under the hood, the results are the same - someone gets elevated permissions. What they DO with those permissions is something you control in your app/tool.

Also, that whole post reads more like an “if you break it you can’t blame us” discord instead of providing real information for users (aside from the lite treatment of sudoers). Sorry if that feels like a slight, but it reads more like CYA than useful, usable information.

Tim Jones
(BOFH) Bastard Operator From Hell since 1982 (SunOS, SCO, A/IX, DG/UX, IRIX, PTX, SysV, Ultrix, CTIX, and so many others …)
Linux hacker since 1993 (0.99pl12)
BSD386 hacker since 1995[/quote]
I’m no linux master, very far from it. I only know what other more experienced users/gurus tell me. With your background, obviously I have to listen to what you say, and what you say makes perfect sense. However, sudo is not installed on my distro by default, so users WOULD know about it since they’d have to choose to install it. I have it on my system…given the post I linked to, chances are good that most others don’t. As for using gksu, I don’t see how I have much choice, given the above-discussed various limitations. After a great deal of googling, it’s the only viable option I could find that accommodates the given issues, and in all other functions in my app it works flawlessly. Originally, I designed this app only for myself, but was made aware that others could benefit from it as well and that it belongs on the distro’s repo. That’s the only reason I am putting in the time & effort to figure all this out. I’m still very much a noob, so this has been incredibly difficult…but worth it to sure. Thanks for your input and time. :slight_smile:

While not giving a child a hammer will prevent him from putting holes in the wall, NOT giving him a hammer will prevent him from learning how to properly use a hammer when guidance is provided. Same applies here - limiting the system functionality, while preventing the user from making an unexpected mistake, doesn’t allow the user to learn and limits the usefulness of the system in the long run.

While you could mask “su” in a similar manner as above, that means that the user running the app would need the root user password rather than their own password. THAT is the biggest security hole that I could ever imagine.

But, as a BOFH, I’ve always believed that computer users should be forced to pass a test and get a license to use the system outside of data entry tasks … :S

I’m not entiely certain of everything you’re trying to say here, some comments do come across as less than complimentary. Dare I say insulting? I appreciate you taking the time to respond, and I have been nothing but respectful. Let’s just call this thread done. I have no time for ego or attitude. So long and thanks for all the fish.

Tim isn’t a person to insult anyone, only tries to help and warn, i don’t see anything in his words that can be explained as rude or insulting.

Maybe you’re right. I apologize. It was a very long day filled with intense frustration…maybe I over reacted. Sorry, Tim.

I didn’t create this app to stop anyone from learning. Like all apps, it was meant to make things easier. During my long hours of googling during its development, I discovered a great deal of confusion over how to configure OpenVPN…and even more confusion due to the multitude of solutions which were often pretty convoluted. My intention was to help remedy this problem, and to a large extent, I succeeded. But I see now that my methods are less than satisfactory, and I have exhausted myself trying to solve those issues…I am still, after all, fairly noob-ish. I think maybe it’s time to just flush the project since I just can’t seem to appease the users of my distro (who have been warned against sudo) AND avoid the security issues involved with using gksu (it’s been deprecated anyway). And to be perfectly honest, I don’t “get” pkexec at all. The bottom line is my original intention is beyond my scope to achieve right now. I know that sounds defeatist, but I think I need to recognize my limitations. Thanks for all the assistance.

Bill, my apologies for the confusion on my position there - my comments are aimed at the creator of PCLinuxOS, not you - definitely. My point is that by “protecting” users by crippling the Linux installation, they are really not doing the user any favor.

Don’t let their holier-than-thou position on sudo prevent you from continuing with your project - remember, there are a LOT of additional Linux distributions out there and PCLinuxOS has a very small footprint in the overall scheme of things. Configuring VPN settings is a PITA on the best Linux distribution, so if you have a helper tool that simplifies this, please continue working on it.

Thanks for clarifying, Tim. I appreciate that. Over many years, I have periodically tried out various distro’s, but I always ended up back at pclinuxos. I just find that how things are set up comes naturally to me and therefore it feels natural using it. As a “life-long” windows user/geek, it made the full time switch to linux very easy. I’m not saying “it’s the best”, only that it suits me well. Windows 10 was the final straw for me…I just couldn’t stand any more BS so I switched (very recently) and I can’t say I miss windows one bit. :slight_smile:
As for my app, I’m a bit of a pitbull with things in general. Once something is in my jaws, I just can’t let go no matter how much I may want to. Since my last post, I did actually solve all the issues I was having. Solved one, and the rest were a cascading effect. My only regret is that it will not work on a distro that uses systemd…but that’s a problem for another day.

Actually, it will work on a systemd system. All of the systemd implementations still call out to the rc.d/init.d stuff as part of the compatibility layer.

For example, we still use init.d for our BRU Server server and agent daemons because it works on ALL systems instead of just a few.

Ok, I just know this is going to turn out to be another bonehead move on my part, but I’m not using init.d, I’m using rc.local
<insert b*tch slap here>
I’m showing my ignorance again, aren’t I?

Sorry for not being clear there - rc.local IS init.d/rc.d :D.

To clarify - we basically have 3 startup script environments:

  • Red Hat-style rc.d/init.d (SysV)
  • DebIan-style rc.d/init.d (BSD)
  • systemd

Basically, for the non-systemd systems, you will have /etc/init.d and then the rc folders will be split into either /etc/rc.d/??? and sub-folders, or /etc/rc[0-6].d folders. Then, you will find an rc.local, local.rc, or rc.d/local file for non-system init items. There are outliers, but those are the primary methods across almost all Unix platforms.

Grooooovy! Thanks for the info!