Group Management and Shared Directory
Nick Rogers
I have a problem with a group writable directory. Scenario: I have a
directory that needs to be able to allow group read, write, delete,
modify, and the group should own all files/subdirectories therein.
Should be easy, right? FWIW, this is on SuSe 10.2 Server.
I created a group to contain all of the users, named testgroup.
groupadd testgroup
I then created a series of users to add to the testgroup:
useradd -G testgroup -md /home/testuser1 testuser1
...
Then, I created the directory all need to be able to read and write to:
md /home/testdir
chgrp -R testgroup /home/testdir
chmod g+w /home/testdir
ls -al /home
drwxrwxr-x 2 nrogers testgroup 48 2009-06-15 23:12 testdir
I've tried setting sticky bits and setgid bits on testdir, and I still
have to manually go in and change ownership, and delete/modify aren't
working. Any thoughts? What's the best way to do this other than a
cron that runs every 5 minutes?
Jeffrey Watts
1) New users get added with their primary group set to the same as their username, and a secondary group membership of testgroup. This is very important otherwise home directories won't work right. useradd -g fred -G testgroup -m -d /home/fred fred
2) If the whole system will be working on this scheme, add the following to /etc/profile. If only a select few, add it to ~/.bash_profle. The latter is better, as if you're not using the user-group scheme, root will become vulnerable unless it's updated. umask 0002
3) Set up the group to be owned by the testgroup with the setgid bit set. mkdir /home/testuser; chgrp -R testgroup /home/testdir; chmod -R g+rwxs /home/testdir
4) Profit.
That's it. If you use a distribution like Fedora or RHEL that has user-group already set up, all you need to do is step #3. Enjoy. If you need more fine-grained user access, or if you're not willing to set up user-group, then look at using ACLs. setfacl and getfacl are your friends, but for most Unix folks there's a bit of a learning curve with ACLs.
Jeffrey.
"He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself." -- Thomas Paine
Nick Anderson
> working. Any thoughts? What's the best way to do this other than a
> cron that runs every 5 minutes?
I would first try using acls instead. But I have had a similar
situation where I needed to enforce a bit more complex permission
structure and I had a horrible time getting the inheritance to work
out right. I ended up writing a small python daemon that watched for
inotify events and fired off aubprocesses to fix permissions. Since I
was monitoring with inotify it only fired off the subprocess when a
file was created or moved. Im not a developer so the code is probably
ugly but it worked last time I tried it. If you want it let me know
and I'll try to dig it up.
Christofer C. Bell
On Jun 15, 2009, at 11:17 PM, Nick Rogers <nro...@gmail.com>
> working. Any thoughts? What's the best way to do this other than aI would first try using acls instead.
> cron that runs every 5 minutes?
--
Chris
Jeffrey Watts
J.
I'm curious why you'd go the route of ACLs when the OP's requirement is specifically the situation the group sticky bit is designed for.# chgrp project /path/to/directory# chmod 2775 /path/to/directoryAnd place everyone you want to have permissions to that location in the 'project' group.Is your need for ACLs related to having a more complex permissions scheme?
--
ni...@anders0n.net
> specifically the situation the group sticky bit is designed for.
> # chgrp project /path/to/directory
> # chmod 2775 /path/to/directory
> Is your need for ACLs related to having a more complex permissions scheme?
My initial reason for using ACLs was because I had a more complex
permissions schema. But after using ACLs for a while almost any time I
need to give different permissions based on group or user I default to
ACLs. Its simpler for me to just use the same thing all the time. Since I
am already using ACLs if I need to do something more interesting
permission wise its not a "chore" to do so.
Billy Crook
> I have a problem with a group writable directory. Scenario: I have a
> directory that needs to be able to allow group read, write, delete,
> modify, and the group should own all files/subdirectories therein.
> Should be easy, right? FWIW, this is on SuSe 10.2 Server.
Assuming the tree of files starts at /mnt/share, and the name of the
group you want to have controll is groupnamehere, run these comands:
find /mnt/share -type d -exec chmod -c g+rwxs,uo-rwxst '{}' \;
find /mnt/share -type f -exec chmod -c g+rw,uo-rwxst '{}' \;
chgrp groupnamehere -c -R /mnt/share
You can further put them in a cronjob, and they will only send you an
email if there have been some deviations from the permissions schema
which you should probably investigate. Also, be advised the above
lines remove permissions from 'others'.
> Then, I created the directory all need to be able to read and write to:
> md /home/testdir
> chgrp -R testgroup /home/testdir
> chmod g+w /home/testdir
> ls -al /home
> drwxrwxr-x 2 nrogers testgroup 48 2009-06-15 23:12 testdir
>
> I've tried setting sticky bits and setgid bits on testdir, and I still
> have to manually go in and change ownership, and delete/modify aren't
> working. Any thoughts? What's the best way to do this other than a
> cron that runs every 5 minutes?
SGID directories and changing the default permissions mask is the
correct way to go about this. You shouldn't ever have to change the
UID of files and new files will inherit the GID of their parent
directory if the new files are created by a user who was a member of
that GID when he/she logged in. The UID of files in this scenario
will only be relevant for determining who created the file.
As a few people have mentioned so far, Posix ACLs (setfacl and
getfacl) offer quite a bit of flexibility. They however do tend to
make things harder to remember or understand later. They also require
the support for extended attributes which is less of a problem these
days, but something to think about. Rsync didn't used to be able to
copy xattrs.
Setting the umask is less than ideal because it affects more than the
specific trees of directories you have in mind. You can either change
everyone's umask for all things, or just some users for all things.
GNU+Linux does not implement recursive permissions or ownership, at
all. The closest thing to it is setting sgid on a directory. This
causes all newly created files and directories within that directory
to be created with the same groupID as their parent if the user
creating them is a member of that group, and with their sgid bit set
if they are a directory.
> I then created a series of users to add to the testgroup:
> useradd -G testgroup -md /home/testuser1 testuser1
I would also advise against assigning a special purpose group as a
user's primary group. Instead, create the user first, and them to the
group. Trust your defaults unless you completely understand, and
disagree with them.
useradd testuser1
usermod -G testgroup -a testuser1
> I created a group to contain all of the users, named testgroup.
> groupadd testgroup
Think of groups as access lists, not as groups of people. (i.e.
create one group per distinct resource, not one group per department
in the company) Groups can not contain other groups.
If your users are working with this directory through cifs, samba
gives exceptional control over how they may interact on a per-share,
per filetype basis. This includes masking permissions.
create mask = 0660
directory mask = 2770
force create mode = 0660
force directory mode = 2770
That would have the same effect as using umask, but only on that share.
glawson
----------snip--------------
postgres=# create database dspace;
CREATE DATABASE
postgres=# \l
List of databases
Name | Owner | Encoding
-----------+----------+----------
dspace | postgres | UTF8
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
(4 rows)
postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";
ERROR: syntax error at or near "TO"
LINE 1: grant all on dspace.* to dspace@localhost identified by "dsp....
----------------snip---------------
Thanks!
--
Greg Lawson
Rolling Hills Consolidated Library
1912 N. Belt Highway
St. Joseph, MO 64506
djgoku
>
> Can anyone help me with some postgresql syntax?
>
> ----------snip--------------
>
>
> postgres=# create database dspace;
> CREATE DATABASE
> postgres=# \l
> List of databases
> Name | Owner | Encoding
> -----------+----------+----------
> dspace | postgres | UTF8
> postgres | postgres | UTF8
> template0 | postgres | UTF8
> template1 | postgres | UTF8
> (4 rows)
>
> postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";
> ERROR: syntax error at or near "TO"
> LINE 1: grant all on dspace.* to dspace@localhost identified by "dsp....
Maybe try:
GRANT ALL ON dspace TO dspace@localhost IDENTIFIED BY "mypassword";
Notice I removed the .* after dspace.
More info at: http://www.postgresql.org/docs/8.1/static/sql-grant.html
Jonathan
djgoku
> On Tue, Jun 16, 2009 at 11:39 AM, glawson<gla...@rhcl.org> wrote:
>>
>> Can anyone help me with some postgresql syntax?
>>
>> ----------snip--------------
>>
>>
>> postgres=# create database dspace;
>> CREATE DATABASE
>> postgres=# \l
>> List of databases
>> Name | Owner | Encoding
>> -----------+----------+----------
>> dspace | postgres | UTF8
>> postgres | postgres | UTF8
>> template0 | postgres | UTF8
>> template1 | postgres | UTF8
>> (4 rows)
>>
>> postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";
>> ERROR: syntax error at or near "TO"
>> LINE 1: grant all on dspace.* to dspace@localhost identified by "dsp....
>
> Maybe try:
>
> GRANT ALL ON dspace TO dspace@localhost IDENTIFIED BY "mypassword";
Err.
Before you do the grant statement you probably need to create that user:
http://www.postgresql.org/docs/8.3/interactive/app-createuser.html
http://www.postgresql.org/docs/8.3/interactive/sql-grant.html
GRANT ALL PRIVILEGES ON dspace TO dspace;
http://www.revsys.com/talks/kulua/basic-postgresql/basic-postgresql-administration.pdf
Jonathan
Frank Wiles
Can anyone help me with some postgresql syntax?
postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";
ERROR: syntax error at or near "TO"
LINE 1: grant all on dspace.* to dspace@localhost identified by "dsp....
Well first off, PostgreSQL is not MySQL, so trying to use a MySQL-ism isn't going to work for you.
The easiest way to do what you're wanting is to, if you haven't created any tables yet, is to:
ALTER DATABASE dspace OWNER TO dspace;
The best advice I can give is to read the documentation, it clearly spells out how to do these types of operations. If you're going to get comfortable with PostgreSQL, you really need to get a handle on how users/roles and privs work with it.
You can't bulk set privs with PostgreSQL, but if you google for 'postgresql grant all tables' you will find several shell scripts and pl/pgsql functions you can use to do this.
--
Frank Wiles
Revolution Systems | http://www.revsys.com/
fr...@revsys.com | (800) 647-6298
glawson
---------------snip--------------------
dspace@bloodroot:/opt/dspace/target/dspace-1.5.2-build.dir$ ant fresh_install
Buildfile: build.xml
init_installation:
init_configs:
setup_database:
[java] 2009-06-16 12:04:17,284 INFO org.dspace.core.ConfigurationManager @ Loading system provided config property (-Ddspace.configuration): config/dspace.cfg
[java] 2009-06-16 12:04:17,304 INFO org.dspace.core.ConfigurationManager @ Using default log4j provided log configuration,if uninitended, check your dspace.cfg for (log.init.config)
[java] 2009-06-16 12:04:17,304 INFO org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database
[java] 2009-06-16 12:04:17,604 FATAL org.dspace.storage.rdbms.InitializeDatabase @ Caught exception:
[java] org.postgresql.util.PSQLException: FATAL: password authentication failed for user "dspace"
[java] at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:275)
>
>>>deleted many lines
>
[java] at org.dspace.storage.rdbms.InitializeDatabase.main(InitializeDatabase.java:100)
BUILD FAILED
/opt/dspace/target/dspace-1.5.2-build.dir/build.xml:585: Java returned: 1
---------------snip------------------------------------
I have the password set to "mypassword" in a configuration file (dspace.cfg) used by dspace to build, and this needs to match what postgresql sees for the database "dspace". That's why I was trying the MySQLesq command below. So what I need to do is assign a password for the user dspace using the database dspace, something like the following (which works in MySQL) "postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";"
-----------snip from dspace.cfg-------
# Database username and password
db.username = dspace
db.password = 'mypassword'
-----------end snip-------------------------
Thanks also for the links to documentation--I already had about 20 FF tabs open with various docs including the official postgresql refs and I'm trying to wade through all of them--I just can't figure out how to set the password for the user for that database.
Greg
-----------------------------------------------------
----- Original Message -----
From: "Frank Wiles" <fr...@wiles.org>
To: kul...@googlegroups.com
Sent: Tuesday, June 16, 2009 11:53:46 AM GMT -06:00 US/Canada Central
Subject: [KULUA] Re: PostgreSQL Syntax Help?
On Tue, Jun 16, 2009 at 11:39 AM, glawson <gla...@rhcl.org> wrote:
Can anyone help me with some postgresql syntax?
postgres=# GRANT ALL ON dspace.* TO dspace@localhost IDENTIFIED BY "mypassword";
ERROR: syntax error at or near "TO"
LINE 1: grant all on dspace.* to dspace@localhost identified by "dsp.....
Well first off, PostgreSQL is not MySQL, so trying to use a MySQL-ism isn't going to work for you.
The easiest way to do what you're wanting is to, if you haven't created any tables yet, is to:
ALTER DATABASE dspace OWNER TO dspace;
The best advice I can give is to read the documentation, it clearly spells out how to do these types of operations. If you're going to get comfortable with PostgreSQL, you really need to get a handle on how users/roles and privs work with it.
You can't bulk set privs with PostgreSQL, but if you google for 'postgresql grant all tables' you will find several shell scripts and pl/pgsql functions you can use to do this.
Jeffrey Watts
I would also advise against assigning a special purpose group as a
user's primary group. Instead, create the user first, and them to the
group. Trust your defaults unless you completely understand, and
disagree with them.
useradd testuser1
usermod -G testgroup -a testuser1
Your syntax is off. -g is the primary group, -G is the secondary group. He was assigning them correctly in his original post.
Jeffrey.
Billy Crook
> On Tue, Jun 16, 2009 at 10:45 AM, Billy Crook <billy...@gmail.com> wrote:
>>
>> I would also advise against assigning a special purpose group as a
>> user's primary group. Instead, create the user first, and them to the
>> group. Trust your defaults unless you completely understand, and
>> disagree with them.
>>
>> useradd testuser1
>> usermod -G testgroup -a testuser1
>
> Your syntax is off. -g is the primary group, -G is the secondary group. He
> was assigning them correctly in his original post.
No, I actually meant that I recommend not messing with the primary
group, and just adding them to a secondary group for each resource
they should be allowed to access. In my mind, if business logic could
dictate they need access to some resource today, they will likely
eventually need equal access to some other resource in the future.
Jeffrey Watts
Jeffrey.
No, I actually meant that I recommend not messing with the primary
> Your syntax is off. -g is the primary group, -G is the secondary group. He
> was assigning them correctly in his original post.
group, and just adding them to a secondary group for each resource
they should be allowed to access. In my mind, if business logic could
dictate they need access to some resource today, they will likely
eventually need equal access to some other resource in the future.
Frank Wiles
>
> Thanks also for the links to documentation--I already had about 20 FF tabs
> open with various docs including the official postgresql refs and I'm trying
> to wade through all of them--I just can't figure out how to set the password
> for the user for that database.
If you're created the database already you just need to do:
CREATE USER dspace PASSWORD 'secret';
User's have passwords, for the system as a whole, not a particular
database which might be confusing you. You control which users can
access what databases ( and from where ) by editing pg_hba.conf in
your PostgreSQL data directory.
Hope that helps!
Russell Valentine
'createuser'.
Can see their man pages.
I personally think the postgresql documentation for sql syntax is great
though.
gladi...@gmail.com
How did this turn into a postgres thread? Where you secretly thinking
postgre thoughts while asking a question about directory permissions?
tsk. Some never learn...
Anyway... this basic idea works in Unix, Linux, BSD, whatever.
Original SysVr4 doesn't inherit the sticky bit when new directories
are created, but I'm pretty sure all derivatives do.
create group playpen
mkdir /home/playpen
chown root:playpen /home/playpen
chmod 2770 /home/playpen # directory group sticky-bit
add all the users that want to play to group playpen.
If your users are happy and peaceful users, add "umask 0007" to the
bottom of your system's default bashrc and have them relog. Then
whenever someone creates a file in the playpen, it will have u+rw g+rw
permissions. If someone in that group creates a new directory...
login: junior
password: ilikecake
$ cd /home/playpen
$ mkdir wheeee
$ touch something
$ ls -l
total 40
drwxrws--- 2 junior playpen 4096 Jun 17 14:42 wheeee
-rw-rw---- 0 junior playpen 0 Jun 17 14:42 something
$
If they are evil, crazy, tool-of-satan types and make personal mods to
their $HOME/.bash* files, you may just have to resort to telling them
to set their damned umask or they won't be allowed in the playpen.
---
re: ACLs
Nick is correct in so far as ACLs are a technically superior
solution. Once you get your head around them, they give you the
maximum amount of flexibility re: file system permissions. Check them
out if you don't find this more neolithic solution acceptable.
Approach ACLs with plenty of numbing cream, though... you *will* punch
yourself in the sensitive bits many times before mastery is
attained. If you have any sensation left at all, you should jump
into SELinux. I mean, after Abu Grab, Guantanamo is a cake-walk,
right?
-Stephen