Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
The colon at the end is correct. Make sure that you don't have the user or users group as the default group for root. Make sure that the the /root directory and files have root ownership and root group ownership and that the "o" permission bits are cleared.
Make sure that the UMASK variable for root masks out the other bit on newly created files.
Also check the group membership of each of the members. The line you have shown shows who are members of the "user" group.
Check the permissions of the commands in /bin and /usr/bin. See if some of them are SUID root. If so, when they run, they run as the owner of the file, which would be root. Only a small handful of programs should have the SUID bit set. Also make sure the GUID bit isn't set on the /bin and /sbin and /usr/bin and /usr/sbin directories. That would have the same effect, giving group membership to any user running such a command.
If you find that a large number of programs have the suid bit set, you better figure out how and when it happened. If your system has been on the net, and someone was able to crash a service they may of been given root access by simply running /bin/bash, if bash is also suid root. You may consider re-installing, because with these permissions problems, you can't trust any program anymore, and starting from scratch would be the safest thing to do.
There is a distro that is sold in stores (LINSPIRE) that gives every user root access. This is so people accustomed to running Windows 98 don't get put off by having to enter the root password to install programs.
I don't know whether Gentoo uses PAM and the shadow suite. You may also want to examine the /etc/gshadow file. The third field lists admin members, which may cause a problem.
You may try an experiment. Create a new user, and log in as that user. Don't make this user a member of any special group. See if this new user also has root powers.
As the regular user, type in the groups command to see which groups you are a member of.
If you are a member of the wheel group, then what you see may be normal. I'm not sure about the "disk" group.
Create a new normal user. Lets say that this new user is a member of the groups: users dialout audio cdrom video
I bet that the test you just performed will not succeed this time. This would be good news in that you don't have a permissions problem for ordinary users.
Yes, gilead, you are correct. It is because the user has write permissions in that directory, and has nothing to do with being a member of the wheel group. ( Where was my brain? )
Pingvina, when you delete a file, you are not writing to the file, but writing a change to the directory. In your home directory you have write access so you can do that. To the kernel, the directory is actually a file, and it is the permissions of that (directory) file that is checked. The /tmp directory is the one directory that is globally writable and so the sticky bit is set for it.
If you own the directory, you will still be able to remove a root owned file in the directory, even with the sticky bit set, according to the coreutils info page:
3. save the program's text image on the swap device so it will load
more quickly when run (called the "sticky bit"). For directories
on some systems, prevent users from removing or renaming a file in
a directory unless they own the file or the directory; this is
called the "restricted deletion flag" for the directory.