Benjamin Vander Jagt wrote:
So the permissions on the destination directory are set worng, or you shouldn't be putting files there. Ask teh owne of that directory to
give
you write permission.
I once tried "chmod 777 / -R", and I ended up with a system where everything was accessible by everyone... then I discovered that most of the internal stuff does not like when its mode is changed, and the system didn't boot again... :-)
Many things will complain then. That's because you are circumvention the protections. I remeber something that wouldn't work if a file in $HOME was world readable.
how about use root to cget write permission #su #chmod a+w /some/directory
copy the files using you nautilus selection The restore the permission settings
# chmod a-w /some/directory # exit
sounds like a lot of work, then I adjust my settings in, say,
I ment as a work around when you have selected lots of files as some user and need to put them somewhere you don't have premission. Instead of starting nautilus as root and reselecting, just use root to change the directory you are trying to write to.
/etc/modules.conf, then do the whole thing over again? I'm okay with doing a bunch of extra typing if I have to, but how 'bout everyone else in the house? I'd rather just browse to it in Nautilus, double click it, and modify it. I would love it if it put up a login screen whenever I double-clicked a file I didn't have permissions to, but it doesn't.
Why would "everyone in the house" need access to that?
I haven't touched modules.conf in months. Most hardware changes don't even require access to modules.conf.
I might be more satisfied if I make an extra set of icons, like "Nautilus as Root" or "Terminal as Root". (I remember there was a way to do that. In fact, I did that once, but now I don't remember. It definitely wasn't sudo. I think it was su.)
I remember the root terminal. Not sure where it went or why.
Most admin tacks in the GUI will ask for root's password whne it's needed. RHL even caches it for a short time, so if you have severalk tasks to do you don't have to keep typing the password.
Show them how give others permission to access their directories.
full root access is again ovekill. The don't need to write to system directories like /bin or /usr/lib, just each others data directories.
It jsu permission problems.
really? they don't need to write to system directories, like /bin or /usr/lib? what about when installing, modifying, or updating GATOS or AIM native?
Confused here. How often are you plan to update things like that? Still, installing software: Open terminal sudo rpm -Uvh package.rpm done.
Nautilus might ask if you try using it to install too, not sure, I don't use nautilus to install. (One of my big peaves about windows is having to use the GUI for thangs that are much simpler with the command line)
Not sure what AIM native is, but the users could/should prpobably install it in $HOME instead of system wide. I have personal version of many apps in $HOME/bin, like OO.org and mozilla, that are too unstable for system wide uses, or might break someone else workflow.
Imagine how you feel if some user changed mozilla system wide and your plugins quit working. Or I change the version of perl and you scripts broke.
when I ran my system as user, I made it a habit to go into terminal, su to root, and run nautilus to do everything, 'cause I hated getting part
Like what. You should seldom need write access to system files and directories.
Are you new to Unix? Ever use it in a university or work environment?
Few people in those setting have root access, and it works fine. Better than windows, since the user cannot trash the whole system by soing something stupid. (try "rm -Rf /" on *nix and "deltree C:\" on windows)
It takes some getting used to, but you learn how to seperate user data from system data. You will seldom need access to the system data then.
yeah, I do want users installing software all over the place. all our data is secure, and we always have extra RedHat discs around. the fact
What about the lost productivity waiting for the system to reinstall, and the data to be restored?
is that we have never caused any problems by running around as root that we would not have caused anyway by su-ing to root. when we want to install software, change settings, or otherwise screw with the system, we will. either we have to su to do it, or we stay logged in as root...
But a users doesn't need to configure X, or change the network settings do they? Why would you want users installing random software on the systems?
I beg to differ. I don't think that giving root access defeats that
completely. ("that", being "global file ownership") I see giving root
access as solving that completely...
as far as setting group permissions, that works in FreeBSD, but not any Linux that I've seen. in FreeBSD, I can just add a user to wheel. when I try chown-ing to give the group "user" access to system files, sometimes the system refuses to use the file, saying that it's not the original. this usually results in a system that doesn't boot...
Right, you make the user a member of the group. All the lab users are members of the group lab. They can access all data related to lab work. Non lab users cannot.
Users do not need write access to the system files.
this is how I would prefer my Linux box...give a user administrative permission. sudo is a pain to use, and I might as well su if I know the password. changing modes or owners results in a system that doesn't boot. therefore, I just use root.
I remember when I was first introduced to *nix and the concept of users versus administrators. I felt the same way. I came for single user OSes, Commodores and Ataris. Then I got the chance to be root on my own *nix. After trashing the system a few times, I went back to running as a user 95% of the time.
Like this in .xsession
#!/bin/sh xhost +localhost gnome-session
umm, yeah... where is that file? I expected it to be in ~ like in other distros, but I can't seem to find it...
YOU create it. just like other optional files. I'll be you don't have .rhosts or .Xclients either. How about .less or .lesskey ("man less" to see what they do)
-Thomas
