[SOLVED] Generic Security Question

[bscalise]

There's a UID associated with my user login of 500, as is the group: 500. In almost every other distribution I've tried the UID for both USER and GROUP is 1000. With a UID of 500, I couldn't access files on my other hard-drives normally. Sometimes I could see them but not delete them, but mostly I couldn't write anything. It appears that for the purposes of PERMISSIONS, the USER and GROUP isn't actually used, even though the file manager will show the USER name and GROUP. It appears really the UID is written, and then the OS just matches the UID to whatever username is the same. So I went about changing my file permissions with chown to make my new username the owner of the files. In retrospect, this may have been the wrong approach. I would have thought that each UID of a lower number had higher privelages, but with a 500 UID I couldn't delete files where 1000 was the owner. Whether 500 or 1000, a UID seems largely arbitrary. I tried to create a new user so it'd have 1000 as the UID, but I would need to delete the old userid and start a new one. In retrospect, this would probably have been a better course of action than chown to the username (which is always consistent whatever distribution I'm using), which presumably now is really putting a UID of 500 as the owner, and not actually the name. My results suggest to me that in a multi-user system nobody would have the same UID, and that permissions would be managed largely by group membership.

Questions:

1) Is my supposition incorrect in any way?
2) Why would Mageia choose 500 instead of 1000?
3) Is there some better way to effectively manage permissions than deleting and creating users with various matching UIDs &/or messing with chown?
4) What managing permissions on a multi-user system?

I know this is a lot, and I know its a generic question, but it only came up because Mageia is using the UID of 500 vs. Ubuntu, Kubuntu, Debian, SID, Opensuse, Mepis, and seemingly 50 other distributions use 1000. I have installed and used over 60 different distributions, and only came across this issue one other time a number of years ago.

[wintpe]

permisions in Unix/Linux

Ok a couple of things you have said are wrong. but in general you have the right idea.

there are only two classes of user in Unix (there is a third also, but that does not realy apply here )

uid 0 is root ie super user

password file on solaris

root:x:0:0:Super-User:/root:/sbin/sh

on linux

root:x:0:0:root:/root:/bin/bash

root has the highest class of permisions and can do everything.

Then theres everyone else.

uid 3000 does not have a higher level of access than uid 3001, they are the same.

they are treated to start with the same as nobody.

when the account is created with 500 uid and 500 gid and theres no other user on the system you are isolated as a single entity. If a second user is created with any other userid say 3000 and has a primary group of 500 you start a team, who depending upon your octal group settings will allow you to share files between one another.

You can also have secondary group access by adding your name to the end of (for example group 3000) in the /etc/group file.

so files with uid 500 gid 500 with a mod of 640 or -rw-r----- will be writable by uid 500 readable by anyone in gid 500 but not viewable by any other user but root.

a file of 600 or -rw------- readable and writable by the owner by no one else.

beware directory permisions override file permisions.

so there are 3 octets to a mode, UID, GID, and Other (sometimes refered to as World)

you can use chmod with u+w or g-w or o+r

oh and directories need x otherwise that class cant ls in the directory.

since a file is in a directory, even if you make it not writable by the owner , if the directory is writable it can still be deleted/modified.

why does M* use 500, thats the trouble with standards, theres so many of them.

theres more than just chown, theres chgrp, chmod, oh and dont forget set-uid, set-gid, sticky bit, and if you realy want to go non standard extended attributes introduced by sun a few years that no one has realy adopted.

finaly on drives, the directory mount point perms is important, as remember everything bellow inherets the permisions above, upto the mount point. (well thats probably not the best explanation, but it will help you to learn how it works.)

oh yes, almost forgot the 3erd type of user.

this is the account that is able to do certain elevated tasks such as use system calls that are set-uid on certain banned files.

so for example and this varies across different unix's

shell scripts are sometimes limited to not being used when suid is set to switch user id and a setuid script unless there uid is bellow 100.

on solaris i think this is built in and not changable and is uid 500.

And finaly, to clarify that you are right when you implied that the names assigned to users and groups, are an alias, and simply to make listings of files and there permisions human readable.

tools like chmod do use the names, in arguments for convinience only, for example an NFS server that has no link to the password and group file, like a NAS will honner giving out files if the UID matches and does not care about the name, except when the uid = 0.

if the UID is 0 the NFS server will squash it, to nobody, unless the option in the share says root=servername

if you login to the server and do a listing all files will only show uid/gid, unless linked to a central uid/gid database such as NIS or ldap.





regards peter

[djennings]

As wintpe has pointed out there is no concept of higher UIDs having higher permissions.

It makes entirely no difference what your UID is, you can only read or write to a particular file if either you own it, you are a member of a group with permission, or the file is available to anyone.

The same goes for networking. You can only read a file over NFS or Samba if you have the correct permission profile.

There is another special case which is Windows partitions. VFAT has no concept of permissions bits so when a vfat partition is mounted the permissions are spoofed with a 'umask' and every file on the partition will appear to have a set ownership and permission bits. This is configured when the partition is defined in diskdrake.

People often get confused with permissions in Mandriva based distros like Mageia because while many other distros will allow you to set any permission you like on any file, Mandriva based distros have 'msec' Msec is Mandriva Secure (or Mageia Secure) it is an application that manages security on your computer and checks for insecurities an attacker could use to attack your computer and can fix the insecurities depending on the security level you have selected. As part of msec it will scan your computer every hour to see if any files have 'unsafe' permissions set and will either notify you or change the permissions back again. When you know about what msec is doing it is quite simple to control. If you do not want msec to operate at all it can be disabled, you can choose your security level, and you can customise which of the security checks is run. You can also customise what permissions are considered correct for any folder on your computer. You can read about msec here
http://wiki.mandriva.com/en/Msec

[bscalise]

AWESOME responses. THANKS!

I've marked this as solved!