Access Permission

[Soumen Ghosh_1]

Hello,

Suppose, I have two user accounts on my system : abc, group users and xyz, group practice. Their home directories are /home/abc /home/xyz respectively.
abc has given write permission to everybody ( 777 ) to the /home/abc directory.
So obviously, whenever abc creates a file under /home/abc, its owner will be abc and group will be users.
What I want is that whenever xyz creates a file under /home/abc, its owner would be abc (not xyz) and group will be users (not practice).
I could do the second one by making on the group suid bit on /home/abc directory. As a result, whenever xyz creates a file under /home/abc, its group permission becomes users not practice. But I could not do the first one (i.e. making user permission abc not xyz).
Any work around?

Thanks in advance.

Soumen Ghosh

[Steve Steel]

Hi


I do not believe you can do this because it would be a real security risk.

You hace gid so the user will need to do a chown afterwards


Steve Steel

[Stefan Farrelly]

To make the user set uid work the owner of the dir must match the uid of the user - ie the owner of /home/abc must be xyz, not abc. This may affect abc logging in though if his home dir is owned by another user - unless you have world write on (which you do).

[Chris Wilshaw]

There is a way to do this, but it's very bad practice from a system security point of view.

You could give user abc and user xyz the same UID number in /etc/passwd (the third field).

As long as abc was before xyz in the passwd file, any files that were then created by xyz would be displayed with the owner abc

eg:

abc::456:20:ABC User:/home/abc:/usr/bin/sh
xyz::456:20:XYZ User:/home/xyz:/usr/bin/sh

as user abc

cd /home/abc
touch abc.txt
ll abc.txt

-rw-r--r-- 1 abc users 0 May 22 14:36 abc.txt

as user xyz

cd /home/abc
touch xyz.txt
ll xyz.txt

-rw-r--r-- 1 abc users 0 May 22 14:36 xyz.txt

The default group of users has been left in place in the example.

[Bill Hassell]

And as a general practice, 777 permissions should be viewed as a MAJOR security problem. Not only can everyone create files in that directory, but anyone can REMOVE or RENAME files in that directory. So even if the file has no write or read permissions for anyone except the owner (ie, 400 permissions), the file may be replaced (removed and re-created). I would not allow 777 directories for any directory that contains important files (and of course 777 or 666 permissions on a file means that the content is always untrustworthy).

[Vytautas Vysniauskas]

Hi,

Definitely, creation of 777 permision on user directory is very bad practice and big uncontrolable security hole (especially if you have many users on the system). Of course, this can be used as a short, temporal mean to proceed some specific task. But don't use it as a permanent solution !

It looks the crucial thing you need to achieve is that a group of users could work on the same files/directories and have r/w access. Simple and classical approach is as follows

1. Create an additional group (say 'shared') which is used to assign shared priviledges for users.

2. Configure for users 'abc' and 'xyz' additional group 'shared'

3.Change permissions on /home/abc:

chgrp shared /home/abc
chmod 775 /home/abc
chmod g+s /home/abc

Now everyone who is in 'shared' group have priviledges (if default UMASK is 022)

a) create files and directories
b) delete/edit own files and directories
c) delete any top level file and directory under /home/abc
d) r/o access of other files.

Also user can decide to allow r/w acces for other users in 'shared' group by changing permissions

chmod g+w (for files)
chmod g+wx (for directories)

If it sounds complicated then users can set UMASK to 002 and all newly created files and directories will have r/w access for the group 'shared'
In any case usage of world-wide permissions is completely eliminated.

If this scenarion is not suitable, probably you should look for ACL (access control list) extensions for HP_UX kernel. It allows more subtle access control over files and directories. But I don't know if it exists. At least other Unix flavors like BSD, Linux and Solaris (I guess) have such patches.

Have a nice day,

Vytas.

[Wodisch_1]

Hi Soumen,

with "swapmemon=1" you do only need physical swap-space for at least 25% of your RAM...

HTH,
Wodisch