Mac Forum / Programming / Perl / September 2003

Let's back up a bit.  Explain, in more abstract terms, what you're
trying to accomplish.  That may allow enough wiggle room to allow
a Unixish solution.

-r

Hello,

At the risk of spouting off before getting more information (this is
something I think I can actually contribute to, after all), what you're
probably looking for is the sticky bit in the directory permissions.

What it boils down to is this: you set the sticky bit for the directory
and only the owner of the file can delete it. The other users still have
the ability to read/write/execute according to permissions on the file,
they can even create files in the directory (if permissions allow) and
then only they can delete them (other than root, of course).

Obviously this doesn't prevent someone with write access from replacing
the contents of a file with garbage. And there might be situations where
this is not fool-proof... for example: "On most BSD UNIXes, files are
owned by the group that owns the directory in which you create the file."
Does that mean that anyone who is a member of the group who owns the
directory may delete another users file in that directory? I don't know.
Maybe setting the directory to a group that has no members and that has
world rwx permissions would solve that.

I haven't used the sticky bit much myself, other than dabbling with it to
grant access to, but prevent accidental deletion of, digital photos.

Oh, you set the sticky bit thus:

chmod 4775 directoryname

or I think this works, too:

chmod u+t directoryname

Good luck, Jennifer

It shouldn't prohibit them from making changes, unless the editing
tools they're using are trying to overwrite the entire file (or create
a temporary file then replace the original) rather than just modifying
it.

Here's an experiment I tried - notice that I was able to edit the file:

----------------------------
% ls -al
total 8
dr-xr-xr-x    3 ken  staff   102 Sep 23 09:13 ./
drwxr-xr-x  208 ken  staff  7072 Sep 23 09:13 ../
-rw-r--r--    1 ken  staff     8 Sep 23 09:13 file
% cat file
content
% emacs file
% cat file
content
more content
----------------------------

If this kind of thing doesn't seem workable for your situation, I can
think of two alternatives:

 1) Keep the information in a relational database, where you can
specify the privileges in a more fine-grained and appropriate manner

 2) Write a suid script to handle the required modifications

 -Ken

What you want to do is something that Unix was never designed to do.

Simply put, Unix does not give you the granularity necessary to do what
you want to do.

You need ACLs (Access Control Lists) which most Unix variants do not
support.

Unix was built upon a model of "peer-pressure." That is to say, it was
designed in a small lab environment where everyone knew everyone else
and if somebody did something either dumb and stupid, or "oops," their
peers knew about it immediately or could simply walk through the 5 or
10 cubicles necessary to find out who deleted the file, then slap them
up-side-the-head so they wouldn't do it again.

Later as Unix expanded, attempts were made to graft all kinds of
controls on to this primitive "read-write-execute," "User-Group-Other"
construct but they never really worked... especially not the way people
really worked once you got beyond a small group of about 10 people and
about the year 1990. (And their implementations, like with sticky-bits,
varies across Unix implementations.)

It's a difficult problem - you may be able to create extreme straight
jackets on what people can do. But these are normally not at all what
people "want" to do. This is why things like Oracle or Ingress have
been written to bypass the inherent lack of this flexibility at the OS
level and insert it at the application level. Their ability to "store
data" is only a very small part of their feature set. The ability to
CONTROL  ACCESS to the data is their strong point -- who can name it,
create it, read it, update it, destroy it, etc. The ability to sort the
data and present it in different ways is "just a GUI" that rides on top
of the security and control.

T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard - 768 Meg
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg]- Tru64 5.1a
magill@mcgillsociety.org
magill@acm.org
magill@mac.com

That sure isn't the way I understand it. I'll check when I get a chance
whether that's the effect on Mac OS X. Are you trying to use the GUI
File Info interface from Finder, instead of chmod/chown, perhaps?

I've found it handy to set up "dummy" users and "empty" groups. Some
careful thought will often yield the functionality you need. For
instance, the first thing I might try (if I understand your question
correctly) is to set up an empty group called "deptA" with netinfo,
dummy user called "deptA", complete with a file heirarchy under /Users,

BTW, /etc/groups is ignored after Mac OS X goes multi. You'll need to
add users to groups other than their primary group through the
Netinfo Manager utility. (GUI access in the utilities folder.)