[prolix]

here's what I want to do:

setup ssh only users on my os x box. i have linux systems and this is easy to do, just setup the acct. they get a shell, can run bitchx, ftp, whatever.

the problem i see in os x is when you setup a system acct the restrictions seem a bit lax. i setup a test user and i could do all kinds of crap and get into everyone elses file. the user was jsut a 'standard' user, not an admin, but it sure seemed open.

any recommendations about this? all i want is somewhat locked down ssh user. i want them to be able to run some shell programs, but not be able to go browse all teh system volumes at will.

i've seen a couple similar posts but no real answers on this

is os x server any different in how it handles this? is it more locked down in how it handles shell access?

[genevish]

I think a non-admin user can read other user folders, but not write to them. Isn't that standard for most multi-user systems?

Anyway, you can restrict access to the other user folders with chmod. (700 should do the trick, although that could cause problems with other apps). There's also some interesting info here:

http://forums.macosxhints.com/archive/index.php/t-15133

[Detrius]

By default anyone can access the root of your home directory. This is necessary, as otherwise people would not be able to access your public folder or your website folder. It is the user's responsibility to make sure that there is no private information in a location that other users can access.

Otherwise, I don't believe it's easily possible to make a user that can only log in via ssh.

[rkt]

Originally posted by Detrius:
Otherwise, I don't believe it's easily possible to make a user that can only log in via ssh.

with early versions of macosx server (we could possibly be talking as far back as rhapsody - my memory is a little hazy today) there was a netinfo property that would disable gui login for an account. dunno if this feature is still around, but it probably is *if* you know the correct property to add to a user account...

[Gary Kerbaugh]

   Secure Shell doesn't provide a chroot capability like ftp. However, you can get a similar effect by assigning these users "restricted" shells. You can check out a restricted form of bash by invoking it with "bash -r".

   Unfortunately, NetInfo doesn't use arguments to shells when invoking them. If I recall correctly, the way to deal with this is to create a symbolic link named "rbash" that points to bash. Then list that as the shell for the ssh users.

[utidjian]

Originally posted by Gary Kerbaugh:
   Secure Shell doesn't provide a chroot capability like ftp. However, you can get a similar effect by assigning these users "restricted" shells. You can check out a restricted form of bash by invoking it with "bash -r".

Have you tried "bash -r" on Mac OS X? It all but renders the shell completely useless. cd, ls, and just about any other command that is not built into bash (and many that are) will cease to function. In other words I am not so sure that "bash -r" would be useful in this situation.

There may be a way to modify this behavior but according to 'man bash':
"These restrictions are enforced after any startup files are read."

[genevish]

Originally posted by utidjian:
Have you tried "bash -r" on Mac OS X? It all but renders the shell completely useless. cd, ls, and just about any other command that is not built into bash (and many that are) will cease to function. In other words I am not so sure that "bash -r" would be useful in this situation.

There may be a way to modify this behavior but according to 'man bash':
"These restrictions are enforced after any startup files are read."

You can probably create a bin folder in the users home folder and add copies of the commands you want the user to have access to. Here's some info on it:

http://www.mail-archive.com/focus-li.../msg00232.html

[utidjian]

Originally posted by Detrius:
By default anyone can access the root of your home directory. This is necessary, as otherwise people would not be able to access your public folder or your website folder. It is the user's responsibility to make sure that there is no private information in a location that other users can access.

That is not quite correct. In other versions of Unix and Linux the default is to make the users /home/username/ folder mode 0700. /home/username/ in Unix/Linux is the equivalent of /Users/username/ in Mac OS X. Using of /home/ instead of /Users/ is not a hard and fast rule for Unix in general. On Unix systems with a large number of users the location of home folders may be divided by department or whatever... such as: /u/staff/username/, /u/faculty/username/, and so on. It all depends on how the admins set it up. In most all cases I have seen the default mode on a users home folder is 0700 regardless.
So /home/ is just an example.

The problem of sharing subfolders within the home folder is dealt with by setting the mode to 0711 on the home folder. This allows certain subfolders such as ~/Public/ ~/Shared/ ~/Sites/ and ~/WWW/ to be read by all users if the mode on those subfolders is set to 0755. In Mac OS X those 'public' subfolders are set to mode 0755 by default.

I am not sure but I have heard that the reason for setting home folders to mode 0755 in Mac OS X is because certain applications need to be able to read data from that folder. It is not required to have it set to 0755 if the user wants to share sub folders within the home folder. It should be OK to set the home folder mode to 0711 and lose none of the functionality for remote users using ssh to access the system.

[utidjian]

Originally posted by genevish:
You can probably create a bin folder in the users home folder and add copies of the commands you want the user to have access to. Here's some info on it:

http://www.mail-archive.com/focus-li.../msg00232.html

That is interesting... yet I think it will be very difficult to maintain. Perhaps a softlink from the users home folder (~/bin) to a systemwide restricted bin/ folder with the allowed "rbin" binaries.

The other problem I see is that there may be difficult to control side effects of putting a limited subset of binaries in the users ~/bin folder. Some programs may break in unexpected ways and others may allow the user to circumvent the desired security in unexpected ways.

In any case it will be interesting to test it.

Seems to me that the simplest solution is to set all users home folders to mode 0711 and be done with it. For ssh users this would make no difference in functionality of the system except they can no longer read other peoples home folders. Of course it would also not change the ability of any user from reading the normally world readable subfolders.