Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Users and Groups on Linux

Now that I've rebuilt my Red Hat 9 box with Fedora, and installed Out-of-the-Box - I really should get my user and group permissions setup properly. If I ever decide to host CVS, shell access or bug tracking for clients, it'd be nice to know my server is secure. Out-of-the-box installs everything as root (save CVS), so I'm constantly doing "chown -R matt $CATALINA_HOME" or "su" to simply deploy files to Tomcat.

How are these open source servers (i.e. SourceForge) setup? If I wanted to setup a SF-clone, I'm assuming I'd need to setup a "developers" or "clientName" group and then create specific cvs repositories for each client. However, I'm not looking to setup a SourceForge-like server right now - I just want to get my permissions right. I'm thinking of creating a "developers" group, and giving it rw rights to Tomcat, Ant, Anthill, etc. Then I'll make myself a user in this group, rather than having to "su" every time I want to do something. What would you do? How would you setup your "dev" box to be more secure with users and groups?

Posted in Java at Dec 03 2003, 05:45:23 AM MST 1 Comment
Comments:

I've done this a number of times, mostly with CVS repositories but it's useful elsewhere as well. I go the developers' group route, usually multiple groups (cvs, www, java, etc.) One thing that some folks don't know about is the group sticky bit on directories which combined with a umask settings can help maintenance quite a bit. The sticky bit on a directory ensures that new files and directories created in that directory are owned by the group. The umask deals with the permissions of newly created files, so combining the two you can ensure that new files will be owned by a particular group and have permissions to be written by that group.

Last things first: a umask of 002 is group-friendly (new files/directories are created with 664/775), but most unix installs set it to 022. Just change it in /etc/profile or whatever your distro sets it. You need to logout/login again for it to reset, or just run umask from the shell.

To set the sticky bit on a directory, just do:

chmod g+s dirname

To do it in a whole tree of directories, don't use 'chmod -R' since that will set files too (and I'm not sure what that does). Instead:

find dirname -type d | xargs chmod g+s

Now ensure everything is writable by the group:

chmod -R g+w dirname

Should be good to go!

Posted by Chris Winters on December 03, 2003 at 08:52 PM MST #

Post a Comment:
  • HTML Syntax: Allowed