su problem in slack 10.1
 

There are some problems when I su to root:

1. when I work as root using "su", the prompt is not "#" but a "$" as the normal user.

2.
$ su (type in the root passwd)
$ touch aaa ( generate a file named aaa)
$ ls -l aaa
-rw-r--r-- 1 root root 0 2005-04-06 22:21 aaa
$ exit ( exit from root to normal user)
$ rm aaa
rm: remove write-protected regular empty file `aaa'? y
$ ls aaa
ls: aaa: No such file or directory ( the file is removed )
$

3. for a file foo.tar.gz
when I extract it using: tar zxvf foo.tar.gz
and then: ls -l
the owner of the extracted files are one of the normal users in my computer
but not root

Anybody can give me any hint about what is wrong with my system?

OS: slackware 10.1
fs type of /home: ext3

do a quick little test..... log out and then actually log in as root. Create a file then log out and log in as a user and su to root then try to do something with the file. If you are getting errors there then I would check the /etc/groups file and make sure that it didn't get hosed. Also check the owner of home.

Originally posted by subekk0
%% do a quick little test..... log out and then actually log in as root.
That is a remote computer. I can't remote login as root.

%% Create a file then log out and log in as a user and su to root then try to do something with the file.
Fortunately, there is previously a loadlin16c.txt file in /root, which is generated when the system was first installed. And it is write only to root. I can modify the file with no problem when su.

%%If you are getting errors there then I would check the /etc/groups file and make sure that it didn't get hosed.
no error at all.

%%Also check the owner of home.
Following is " ls -l " result for home:
drwxr-xr-x 16 root root 4096 2004-06-07 16:32 home

Any more hint? Thanks.

I would check your /etc/fstab to see if you're not setting a "default" user when creating a file.

My /etc/fstab:

/dev/hda5 swap swap defaults 0 0
/dev/hda1 / reiserfs defaults 1 1
/dev/hda6 /home ext3 defaults 1 2
/dev/hda8 /opt ext3 defaults 1 2
/dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
/dev/hdb1 /home/hdb1 reiserfs noauto,user,exec 0 0
/dev/hdb2 /home/hdb2 vfat noauto,user,exec 0 0
/dev/hdb3 /home/hdb3 vfat noauto,user,exec 0 0

Did you used those commands in hdb2 or hdb3?
Did you tried again in different points and with other users?

I used thoes commands in my home directory.
I just tried to "su" from another user, it has the same problem.

I found the problem for "su" root showing "$" but not "#" prompt. It is because that I set "PS1" in my .bashrc file. When I get rid of it, it works just fine.
However, the normal user can still delete root's file in normal user's home directory. When root extract *.tar.gz, the extracted files will still be owned not by root but a normal user ( may not be the same that doing "su")

Maybe I'm missing something, but I don't see anything wrong with the behaviour in (2) and (3).

If a directory belongs to you (a normal user), you should be able to change it (i.e. its contents), and that means being able to remove any files it contains (regardless of who owns them).

When root extracts a tarball, it will set ownership and permissions of the extracted files to those defined in the tarball itself. However, when you extract a tarball as a normal user, the files will typically belong to you because you do not have permission to "chown" them to somebody else.

Well, now I am confused. You can su to root but you can't login as root? Is this a computer that is shared that via the Web that you have shell access to and a "virtual server" that you are root of? If that is the case it might be a problem with how the virtual server was setup? Generally if you can su to root you can log in as root.

Originally posted by Nobber
Maybe I'm missing something, but I don't see anything wrong with the behaviour in (2) and (3).

If a directory belongs to you (a normal user), you should be able to change it (i.e. its contents), and that means being able to remove any files it contains (regardless of who owns them).

I was just afraid that was some security or setting-up problem. It seems that what you said is quite possible. Can anyone please check if you have the same problem on your computer? If there are other systems act the same way, I won't worry about that any more.

When root extracts a tarball, it will set ownership and permissions of the extracted files to those defined in the tarball itself. However, when you extract a tarball as a normal user, the files will typically belong to you because you do not have permission to "chown" them to somebody else.

The problem for extraction of tarball is that the tarball file is a downloaded software package but not one generated by myself.

I usually do a "chown -R 0:0 directory" on a tarball extracted as root - this is quite normal. There's also a tar option for setting default ownership on extracted files (when operating as root): --no-same-owner.

Originally posted by subekk0
Well, now I am confused. You can su to root but you can't login as root? Is this a computer that is shared that via the Web that you have shell access to and a "virtual server" that you are root of? If that is the case it might be a problem with how the virtual server was setup? Generally if you can su to root you can log in as root.

Since the remote-login-as-root is disabled. I just enabled that and the same problem occurs, i.e., extracted tarball has the permission of a normal user, and root generated file in normal users home directory can be deleted by that user.

Thanks. I feel better now for tarball if it is normal.


I just noticed another quite interesting thing. Suppose I am userA. In my home directory, there are two files not belong to me, one is to root with permission -rw-r--r-- and the other one belongs to userB with permission -rw-r--r--. I can delete the one owned by root but can't delete the one owned by uerB with the error "Permission denied". Does that mean normal user's file is better protected thatn root? I can't believe it.

I can't agree with you for this point now. Just as in my last post, I can remove files owned by root but can't remove files owned by another normal user (all files are in my home directory of course).