Albus

Thanks for the prompt reply Steve. I'll let you know how it goes tomorrow, and if this can be closed. :)

I've gathered from reading many posts here that a lot of problems during './configure', 'make' and 'make install' procedures on CE (Community Edition) were solved by upgrading to Official. My question is: Can a system built with a CE diskset use the Official branches in easy-urpmi and do a system-wide upgrade to the same effect?

Sorry for the double.... Case in point. On a brand new install of debian, again command line only, during the install I choose 'run task select' but don't choose anything (this forces a few common things to be installed anyway) and to not 'run deselect'. It compiled the same mysql source fine. Debian is how old now??? The only difference I noted was the presence of g++.

That makes SOME sense. I installed 'minimal' command line only. No packages were selected at all. I'm a purist and like to build everything. I don't use x either. The interesting thing is, it coudn't find gcc-c++ at all until I added the easy urpmi sources, and even then it installed that packages, but for all intents, they were empty or had bad signatures. updatedb \ locate c++ souln't find anything except my libstdc++XXX files.

I would, but in a fit late last night, I reinstalled debian stable. But maybe if you can help me with a few basic questions, considering I'm new to mandrake, I would be willing to give it another shot. 1) I have the 10.1 community install. Are there some development packages that are not included with this version that are in others? I seem to be missing a lot of things, even when "Development" is checked. For example, I had to add some media to urpmi to get bison, flex, and a few other things. I never did find a g++/gpp to install. 2) Do I need the kernel headers? The errors above seemed like an include problem as they reported numerous "*.h no such file" and "undefined function" errors. 3) What's the difference between urpmi mirrors? Is there any "sanity" between them? Is there a "best" server to use? I really want to use mandrake because of being more up to date (supposedly) than debian. This will let me build the latest snaps of mysql and php5, where RPM's are not available. Thanks in advance.

Scenario: 10.1 community, easyurpmi setup, minimal install (command line only - no package groups selected) What compilers/librariees do I need to install mysql-4.1.9 from source? Here's what I currently have... bison gcc-3.4.1 gcc-cpp-3.4.1 gcc-c++-3.4.1 libgcc1-3.4.1 libstdc++5-3.3.4 libstdc++6-3.4.1 libsigc-1.2_5-1.2.5 and maybe a few other things, I'm not sure. The ./configure makes it ok, but the make dies about 3/4 of the way through. NOTE: I've never done this before.

I don't have access to that.

How do I install the patches listed here ... http://www.mandrakesoft.com/security/advis...=MDKSA-2004:151 ... thanks in advance.

I found the answer locate at the following link: http://hills.ccsf.cc.ca.us/~ckan04/project.shtml The snippet in question reads: Therefore we should limit the people allowed to "su" to the root account by editing the "su" file (/etc/pam.d/su) with the following two lines to the top of the file: auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/pam_wheel.so group=wheel This means only those belongs to the "wheel" group can "su" to root. You may add users to this group so that they may use the "su" command. To make it more secure, you may restrict root to login on specific TTY devices. The following command is to add user to the "wheel" group : #usermod -G10 admin (This means to add "admin" to the wheel group ("10" is the numeric user id of "wheel") and "admin" is the user that belongs to a supplementary group "G".) Conclusion: The same practice can be used to limit access to a variety of other system utilities. Thanks for your patience linux_learner. I hope this information aides others in setting up thier systems more securely. The entire linked page is worth reading. It both explains things and gives exampels. :)

More specific then: When you install Mandrake, assuming you choose "Higher" as the security level, when you are faced with the "regular user" creation part of the setup program, there are additional options listed under the main items. These items are checkboxes and for each enabled, the user gains execute rights for that item. One such item is the "su" command. Left unchecked, the user would see "command not found" if they typed "su" at the shell. The Question: When you check that box, what files/settings does Mandrake change?

I'm dense. I need examples. Reading alone doesn't work for me. :( Let's say I have five users on my system and I want to keep them all from using "su" except the one called "drew" what do I do? I'm sorry if I'm sounding like a broken record at this point, but the admin guide isn't written for people like me.

Your system seems different from mine. I have a file named "/etc/group" which has all the user gruops listed in it. That's what I was talking about. While I understand what you just said, and know that it occurs, I do not know how to make it happen on my own. For instance, on my mahcine, right now any user could "cd" to, and "ls" the contents of any directory on the system. I have no clue how to change that without accidentally destroying it. Some services require certain levels of access and figuring out who they are and what levels are required is beyond me at this point. Let me make this simple by stating one task at a time, and see if sombody can tell me how to do it step by step. (Googling for answers just doesn't help) Task 1: Adjust the system so that, by default, newly added users cannot run "su", "cpp", and "make". I'll glean other restrictions from the answer to this. Please, if anybody has the answer, don't hesitate to jump in. Don't let linux_learner go this alone. He's helped tremendously already.

I'll try it tomorrow. But I don't have a wheel in my /etc/group file at all. slocate finds only one entry for wheel period: pam_wheel.so :so I am assuming that this particular pluggable module isn't being used anywhere, although I'll check it out to be sure.

Yeah, that part I got. I just commented out all the entries in securetty to keep root from logging in anywhere, even locally, but I'd still like to control who can run the su command in addition to that, as well as apply a similar principle to other proggies, like cpp, x, and so on. Let me state what my approach would be and see if it jibes... 1) Create some new groups like susers (for su support), cusers (for compiler support), and so on. 2) Adjust the ownerships and privileges for the individual proggies such that only members of those groups can use them. For example, only those in the group susers can use the su tool. 3) Add members to the new groups, as a secondary group, so that thier initial dedicated group remains untouched. Is this about right?

While I wait for an install to complete, can you answer this: what utils are responsible for the added security introduced at higher levels where users cannot su, access compilers and things like that?