Set owner of folder xxx to -1
 

In this thread I describe what I'm trying to do: send a Unix command-line instruction via SSH session to a server to make a specified folder so that it can't be

• renamed
• deleted
• moved

but can still have stuff put into it, taken back out of it, renamed, etc etc etc., and furthermore that folders parallel to it can be created, renamed, or moved until/unless I do a similar permissions-setting on those folders as well.

No one solved that one for me, but I think I'm on the right track now.

I can do what I want to do from the GUI of MacOS 9 if I mount the Server volume as "root". See the checkbox labeled "Can't move, rename, or delete this item (locked)? When checked (under root mount of volume), someone with the same volume mounted under an end-user username can open the folder, can create new folders within the folder, can drag-copy files into the folder or its newly-created subfolders, can delete stuff out of the folder, and so on.

Now, since I won't want to AppleScript the process of mounting the server volume as root, and because at least some of the end users will be using MacOS X (the Finder of which has no such bleeping checkbox), I need to know what the hell the Unix OS of the Server is really doing in response to the MacOS 9 Get Info window when I close it.

So I fire up the old Script Editor and I set it to record while I do a Get Info and check the checkbox and then close the checkbox, and this is what Script Editor says I did:
Mind you, when I do a subsequent Get Info and open the Sharing panel for this folder again, the owner is still listed as "root". Under OS X (GUI Get Info) Owner is root (access=read and write), Group is other (access=read and write), and Others = "read and write" as well.

XRay reports the permissions on the folder to be drwxrwxrwx, or chmod 0777, with no obscure options checked.

Anyone got a clue as to what, specifically, it is that has been done to this folder by checking that OS 9 Finder box and/or setting the owner of the folder to "-1"?

Open a Terminal window and run the following command on the folder and show us the result:

ls -lod name_of_folder

(For more details, see again that article on the main macosxhints site that I referred you to in the other thread:
http://www.macosxhints.com/article.p...31017061722471)

DCC450# ls -lod AHunter3Test
drwxrwxrwx 3 root 96 Aug 23 14:32 AHunter3Test
DCC450#

What version of OS X are you running?
And what version of 'ls' is that ?
(Please show us the result of the command: 'which ls')
It seems to be a different version than what I am using (/bin/ls on 10.3.5).

Maybe try it again, this time with the full path (/bin/ls) and also with the "-n" option to display numerical owner & group id's:

/bin/ls -lodn AHunter3Test

I myself am running 10.3.5, but that may not be the answer to the question you thought you were asking.

The server isn't running any version or flavor of Mac OS X, I believe it is a Sun server and is therefore running a Solaris Unix.

"Which ls", entered in the SSH session, yields /bin/ls. And...

---------------

OK, I just exited that SSH session and started a new one, this time with an end-user username and password. And from the command line, I sought to change the name of the folder AHunter3Test. AND IT LET ME.

So, umm, feel free to tell me where I'm misconstruing things, but doesn't that mean that the permissions-restriction is somehow not as the Unix level but rather at the AppleShare filesystem management level?

This is confusing. From the GUI, if I mount the volume using the enduser username and pw, when I do a Get Info (MacOS 9) the checkbox I've described is greyed out. It's definitely differentiating based on the logon account being used. And yet the permissions that can be set by mounting that volume as root and doing a Get Info (MacOS 9) , checking that now-available checkbox, apparently only apply to the AppleShare'd environment. Because the very same user that can't do anything to that folder can rename it effortlessly via SSH from the command line!

And yet, and yet,.....ScriptEditor reported that what I'd actually done when I checked the checkbox was to set the owner to "-1" and that sure sounds like Unix to me :confused:

If I am understanding you correctly, you want to create a folder like the /tmp directory.
Any user can create a file or folder in this directory and modify it. No other user besides the owner can modify the file or folder, and no one can rename or move /private/tmp. Keep in mind the permissions of the directory of the folder enclosing the public folder. That is where permissions are set for renaming the public folder. Because /private is not group or world writable, no one can move or rename /private/tmp. Because /private/tmp has it's sticky bit set, no one can modify things not owned by them.

You are probably on the right track believing that AppleShare has its own permission structure, and it may or may not honor the sticky bit. But this should solve the SSH problem.

Oops - I somehow had thought we were talking about an OS X server.

Yes indeed. It is the AppleShare software that is doing the permissions handling.

Wasn't that ScriptEditor in OS 9 that you were using?
OS 9 has/had no notion of Unix.
But it may have used similar sounding concepts for its AppleFileSharing.

Hmm, good point. I've been in OS X just long enough that I forget the obvious. Yeah, OS 9 did "users and groups" and files/folders did have owners.

So I guess the question is whether or not the AppleShare owner/permissions settings that are stored on the Unix box as part of its AppleShare stuff can be accessed and modified from a command line. If not, looks like I have to set up a dedicated MacOS 9 box to sit around and loop through scripts and set the flags via AppleScript if I don't want the endusers to (ever) have the volume mounted as root.

kfaulhaber — didn't mean to ignore your post. I can't do it the way you've described because end users will be creating new folders (and renaming them from "untitled folder" to their real and final names) all day long. If a folder acquires its undeletable/unrenamable status as a consequence of a flag set in the parent folder, end users would be unable to create siblings of that folder within that same parent folder, or rename them, right?

I am not sure how things will behave in the Finder with an AppleShared path, but lets say you have a structure like this /folder1/public. /folder1 is owned by root and has permissions 755. public is also owned by root and has permissions 777 and also has its sticky bit set. When a user logs in through SSH, they cannot move or rename public, but they can create a file or folder in public, rename it, move it, or delete it. No one other than the user who created it can modify it unless the creator gives permission or and admin comes along and modifies it. However, they will not be able to create or modify anything in folder1, if that is what you were asking. Whether or not AppleShare will honor these permissions, I don't know.

Unfortunately, yeah, that's what I was asking.

I need for "public" (to use your example) to be locked to foldername changes and attempts to delete. But I need end users to be able to create "public2", also in folder1, and then, subsequently, have a scripted routine lock that one as well.

Hmmm....what if I do this?

• via SSH session, logging in as root, chmod folder1 so it is no longer read-only — end users could at this point create folders within it, delete things, rename things, etc.;

• exit that session;

• run the existing AppleScript routine, which will create a new folder within folder1, rename it to the appropriate name, create the 7 subfolders within it, rename them, create the 17 sub-subfolders within those and rename them as well, etc etc;

• via 2nd SSH session, again logging in as root, chmod folder1 to make it readonly again and do whatever else it is you said to do (something called a "sticky bit"?) to make all of folder1's immediate subfolders again locked to direct changes (renaming, moving, deleting) but still allowing things to be saved or dragged into them, renamed, etc.;

• exit that session

Maybe if you told us your high-level goals (i.e. organizational-level, not OS X level) we could suggest a solution.

A Sun server is the host for an AppleTalk-mounted volume1 that will be mounted by 3-4 dozen end users with their enduser-level username and password. It will contain all the various files that constitute the production work for each job, divided up into various subfolders of that job folder, which in turn will be within the client folder.

The end users track all job activity in the Filemaker database that I manage (that's what I do for a living). The routine for creating the Client folder (if it doesn't already exist) and then, within it, the Job Folder and, within it, the first-tier subfolders and, within several of those, the sub-subfolders, giving them all their appropriate names, is all inside of FileMaker in the form of a calculated textstring that equates to an AppleScript which FileMaker then executes. Works nicely under both OS 9 and OS X. We get 20-30 new jobs per day, distributed among the many different clients; we get a new client a couple times per month but sometimes they come in batches.

The end users are 80% MacOS 9 and 20% OS X.

A request has been made of me, that I set it so that the Client Folders, once created, cannot be renamed, deleted, or moved; that the Job Folders, once created, cannot be renamed, deleted, or moved, either. End users need to be able to create, IN THE FINDER, subfolders hither and yon, as well as copy TIFF and Quark and Photoshop-native and all other manners of files into various locations within this hierarchy; and to rename files, delete files, open and edit files, etc etc.

----------

Unix permissions make my eyes cross and glaze over and this exercise is no exception. I can't believe that the method for making Folder X so that it can't be moved, renamed, or deleted depends on priv mods performed on its parent folder!!! Be that as it may, let me repeat my previous question: can I just temporarily reset the permissions on the parent folder (which would usually be a client folder, Client ABC let's say) so that it no longer prevents a person with enduser privileges from creating or renaming folders within Client ABC, then call my AppleScript routine, then set those privileges back? And when I set the privileges back, to all of the previously-existing Job Folders retain their "sticky wicket" flags or whatever they are called, or would they each need to be reset? I assume I'd have to plant a sticky wicket in the newly created Job Folder?

The Sun Server uses Xinet to provide its AppleTalk/AppleShare capabilities. I've got their support geeks trying to find out whether/how it's possible to modify that particular setting from the Unix command line.

So why not just make a folder "Records" where only your script is allowed to create sub-folders (or files)? I don't see why the users need to be able to create random folders or files directly under this "Records" folder. Your script will create them a new folder and they can do whatever they want inside that newly-created folder. And they can create folder & files anywhere else they want on the filesystem. But the "Records" folder is owned by you (or some user account that you choose) and no one else can create anything directly inside the "Records" folder. Doesn't that fit your organizational goals?

You've probably had this explained to you before, but this makes sense since a folder is a container and so moving a folder is an editing operation on the parent folder.

Once the primary structure of each job's folders are created, the folks actually doing those jobs will need to copy files and folders into the appropriate job subfolder.

That's what it's there for — for them to put the stuff that comprises the job into the job folder as it's created. And edit parts of it, delete parts of it some of the time, etc etc.

Do any of your users use SSH to access the server? Most of what we have been discussing is UNIX permissions, which don't seem to apply when shared via AppleShare. With UNIX permissions, there is no way to allow write permission to a nested directory and still keep folder names locked. You can prevent it at one level, but not multiple levels. There is no equivalent to AppleShare's "Can't move, rename, or delete this item" in UNIX. What I am curious about: where does the AppleShare server store this permission data?

Exactly - they will need to add & delete & modify files inside the folders that your script creates. They have no need to create folders at the same level as those that your script creates - i.e. no need to add or delete files or folders directly inside the folder I called "Records" above. (By "directly", I mean inside the "Records" folder and not inside any other folder.)

It seems to me your solution is quite simple:
Create a folder (let's call it "Records") using your own user account:
mkdir Records
Make that folder be writable only by you, but readable and searchable by everyone:
chmod 755 Records
Then use your script as needed to create sub-folders (your Client folders) inside Records and then sub-folders (your Jobs folders) inside the Client fodlers. Make the permissions on the Client folders the same as that of Records so no one else can add or remove the Jobs folders. Make sure the ownership & permissions on the Jobs sub-folders are appropriate for your needs (e.g. make them with group-ownership = staff and readable, writable & searchable by group.)

True.

The script itself, later on in the same day, will need to do so as yet another job gets started. If Job ABCDE is created within the Client X folder, and then things are done to lock the Job ABCDE folder, I still need users to be able to run the AppleScript that creates the folders for Job FGHIJ also within the Client X folder. It's OK if I have a routine that briefly unlocks everything within the Client X folder in order to do so and then locks it all back afterwards. The end users are not going to be messing with stuff at that same level other than through that script.

Nope. I can do so via AppleScript (logging on without user intervention to do things then logging off, using Terminal for OS X and MacSSH PPC for OS 9) but the end users don't SSH. We're more interested in preventing oopsies than we are concerned about malice so the fact that they could is not of major concern to us. Most of them are not very inclined to explore outside of what they've been shown or told.

I was assuming that you would run the script that created the folders, thus the script would have your permissions, the folders would be created as owned by you, etc. That was the scenario I outlined above.
If the script is not going to be run from your account, then you could make use of setuid functionality to have it effectively run as you.
See 'man chmod' and look at the section on "set-user-ID-on-execution bit".
You set this bit with 'chmod +s name_of_script'

I never got a really specific "yes that would work" response to my question, but I'd like to try doing the following:

•*use SSH session to set the permissions of the enclosing (Client X) folder so that all Job folders within it are locked (but not their contents).

• also use SSH session before creating new Job Folders within Client X folder, to temporarily un-set those permissions so things can be created within Client X again, briefly; run the AppleScript; then, from SSH session, set the permissions back again.

So, in baby talk, character for character exactly as I would type the string, what do I type on the command line so as to make the folders within Client X folder protected? What do I type to turn it back off again later? And where does this "sticky bit" thing come into play?

(I have read man pages and tutorials and still don't get it. Please help?)

Actually, I just got off the phone with xinet, and it appears that there is a way to set the appletalk "Can't move, rename or delete this item (locked)" flag on a folder from the SSH Unix command line.

I'll post again with specifics if I get that working, and if that works it looks easier than the Unix solution (which would require resetting the Client folder's permissions every time a new Job folder is created).

Got it :)

/usr/etc/appletalk/kats -l /path/to/folder

That locks the sucker from the command line for AppleShare/AppleTalk users, doing exactly what checking the little checkbox does in the Mac GUI. That checkbox, incidentally, is not visible at all in any shape way or form from a MacOS X Finder but setting that flag locks the folder for MacOS X clients as well.

This is probably xinet-specific.