Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Mar 2001 19:07:20 -0500
From:      Sergey Babkin <babkin@bellatlantic.net>
To:        security@freebsd.org, Wes Peters <wes@softweyr.com>, Robert Watson <rwatson@freebsd.org>, fs@freebsd.org
Subject:   about common group & user ID space (PR kern/14584)
Message-ID:  <3AB3FC38.94711FFF@bellatlantic.net>

next in thread | raw e-mail | index | archive | help
All,

I want to commit PR kern/14584. I've been told that it's good
to discuss it in -arch, -security and -fs. (It has been sort of
discussed on -hackers already, there were not much replies).
So I've posted a message on -arch, and now on -security and -fs.
I've also discussed this idea shortly with Kirk McKusick at 
Usenix-2000 at the BSD BOF and he generally liked it and suggested
to review further.

There is a rather long description in the PR. In short, the idea
is that all the IDs above some value get shared by both users
and groups. That is, not only two users can't have the same IDs
(unless they are just aliases like root and toor) and two
groups can't have the same ID, but an user and a group can't
have the same ID as well. This allows to use the UID field
in the inodes to give permissions in the unified UID&GID space,
and thus give two groups (say, "writers" and "readers") different
permissions to the file wtihout resorting to trickery with
subdirectories. The ID space below this some value is kept separate
for UIDs and GIDs for compatibility with the historic IDs.

In the patch this feature is enabled by a kernel compilation option,
plus even with this option compiled a sysctl has to be set. So
it would not affect the unsuspecting users.

Why not leave it to the real ACLs ?

The problem I see with ACLs is that they break all the standard
Unix commands dealing with displaying or storing the permissions, 
such as ls, tar, cpio and others of this sort. 

Probably the ACLs are _the_ way to go for the high-security 
environments.

But from my personal experience with systems administration of
HP-UX and NetWare in not-so-high-security environments, the careless
application of ACLs tends to cause quite a systems administration 
nighmare. So I personally would avoid them for as long as possible
and use only when really neccessary.

And that seems to be not only my experience. For example, in 
UnixWare the ACLs were implemented and then essentially scrapped 
(never ported to VxFS and left working only as remnants in SFS, 
a version of FFS with ACLs which does not seem to be used by anyone 
any more and which may not be used as a root filesystem any more).

This is the reason why I think that the classic Unix permissions
still have a long live ahead, so some backwards-compatible extensions
to them might be quite usable. 

Any comments are welcome.

-SB

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB3FC38.94711FFF>