Highlighted
kilfinge Absent Member.
Absent Member.
3776 views

NSS file permissions problem

Hello,

I'm trying to set up a file permissions on NSS volume for specific scenario. We would like to create folders for users like:

j_smith
a_white
(...)
All users should have rwcemf permissions for contents of all these folders. But they shouldn't be able to erase or rename parent folders (j_smith, a_white etc.) So I have set the [Public] trustee and granted rwcemf permissions. Also using attrib I'have marked these folders “delete inhibit” and “rename inhibit”. Everything works fine except that any user can modify attributes of these folders and uncheck delete/rename inhibit by clicking on folder properties using Novell Client. I cannot disallow user to modify folder attributes without simultaneously denying a user right to modify /rename the contents of the folder.
The problem is that I don't know how to set permissions only to folder not to its contents. I can do this neither by assigning explicitly a trustee nor using inherited rights filter.

Could anyone help me with this ?

Jakub Kuzniar
Labels (2)
0 Likes
5 Replies
kilfinge Absent Member.
Absent Member.

Re: NSS file permissions problem

Anybody know how to do this ?

Really I don't believe that this is not possible on NSS.
0 Likes
jmarton2 Absent Member.
Absent Member.

Re: NSS file permissions problem

On Tue, 16 Jun 2009 08:46:02 +0000, kilfinge wrote:

> The problem is that I don't know how to set permissions only to folder
> not to its contents.


Rights always flow down. You could modify rights on the contents, but
that would mean having to setup an IRF an every file and subfolder which
is completely unmanageable. Also, you mentioned you added [Public] as a
trustee with RWCEMF permissions. You definitely don't want to do this.
The [Public] user is used for access when someone has not yet
authenticated, so any person who can gain access to this server has full
permissions to those directories without ever even logging in. This is a
huge security hole.

If all you want to do is create home directories, well, I don't see the
need to do additional work with permissions and attributes. In every
environment I've ever seen no one has ever manually configured anything
to prevent deletion of the home directory itself. Typically users aren't
going to delete their own home directories, and once you remove the
[Public] trustee you won't have to worry about everyone seeing everyone
else's folders.



--
Joe Marton
Novell Knowledge Partner
SUSE Linux Enterprise 11 is ready for action.

Joe Marton Emeritus Knowledge Partner
0 Likes
kilfinge Absent Member.
Absent Member.

Re: NSS file permissions problem

Thank you for response


>If all you want to do is create home directories, well, I don't see the
>need to do additional work with permissions and attributes. In every
>environment I've ever seen no one has ever manually configured anything
>to prevent deletion of the home directory itself. Typically users aren't
>going to delete their own home directories,


I' don't want to create home folders. This nss volume will be something
like a garbage. A place were people can share files. This folders will be
cleaned up weekly. Each folder has also a directory quota. Folder and
quota creation, clean-up is automated by a script. So my intention is to fit
nss permissions somehow to facilitate file sharing.

In this scenario there is risk of deleting all files and directories by one user.
I would like to protect against it. In POSIX style file system this is easy to
do and in NSS not. You wrote:

>You could modify rights on the contents, but that would
>mean having to setup an IRF an every file and subfolder which is
>completely unmanageable.


I' am very surprised if this is only one solution. It would be a big limitation
of NSS file permissions against POSIX style permissions. e.g.
suppose we have a user j_smith with home folder named j_smith located
at /home on traditional linux filesystem. j_smith directory has 755
permissions. The owner j_smith can create, delete, modify his own files in
/home/j_smith but he cannot delete the home folder itself, because he is
not the owner of parent directory /home. This would be impossible for NSS.

>The [Public] user is used for access when someone has
>not yet authenticated, so any person who can gain access to this server
>has full permissions to those directories without ever even logging in.
>This is a huge security hole.


Thank you, I didn't know that and this is serious mistake. I will delete
[Public] trustee. I used [Public] to give access for all users, and to avoid
assigning each user separately as a trustee. Should I consider creating
groups for that purpose ?




Jakub Kuzniar
0 Likes
jmarton2 Absent Member.
Absent Member.

Re: NSS file permissions problem

On Wed, 17 Jun 2009 14:46:02 +0000, kilfinge wrote:

> I' am very surprised if this is only one solution. It would be a big
> limitation
> of NSS file permissions against POSIX style permissions. e.g. suppose we
> have a user j_smith with home folder named j_smith located at /home on
> traditional linux filesystem. j_smith directory has 755 permissions.
> The owner j_smith can create, delete, modify his own files in
> /home/j_smith but he cannot delete the home folder itself, because he is
> not the owner of parent directory /home. This would be impossible for
> NSS.


I see what you're talking about now. I'll have to test this out as I
simply don't have the answer.

> Thank you, I didn't know that and this is serious mistake. I will
> delete
> [Public] trustee. I used [Public] to give access for all users, and to
> avoid
> assigning each user separately as a trustee. Should I consider creating
> groups for that purpose ?


You can use either groups or containers. If all users in an OU need
access, simply give the OU permissions then rather than creating a group.

--
Joe Marton
Novell Knowledge Partner
SUSE Linux Enterprise 11 is ready for action.

Joe Marton Emeritus Knowledge Partner
0 Likes
kilfinge Absent Member.
Absent Member.

Re: NSS file permissions problem

>I see what you're talking about now. I'll have to test this out as I
>simply don't have the answer.


Thank you. I will be very grateful to you if you could test it. I still didn't find any solution.

>You can use either groups or containers. If all users in an OU need
>access, simply give the OU permissions then rather than creating a >group.


I will use containters. Thank you.

Jakub Kuzniar
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.