Groups to add.
|
| Author | Content |
|---|---|
| jdixon Jun 14, 2008 4:57 PM EDT |
Steven, you might want to add scanner to that list of groups if you expect to be using a scanner on your system. |
| Steven_Rosenber Jun 14, 2008 5:52 PM EDT |
jdixon, thanks for the tip. If anything, needing to know what groups you must/should add is a valuable learning experience. I was more surprised with Debian, where the user account created during setup has all the groups needed, but accounts created after that are more locked down. Anybody who maintains a system needs to know what groups its users need in order to have things working properly. |
| Bob_Robertson Jun 16, 2008 4:04 AM EDT |
Be more surprised. If functionality is added later (such as scanner, powerdev, plugdev), even the initial account is not automatically added. One of those astounding gatchas that balances the otherwise excellent Debian experience. |
| Steven_Rosenber Jun 16, 2008 10:13 AM EDT |
The thing about groups in Linux/Unix is that I need to learn more about users and groups, especially when it comes to servers. I'm still trying to wrap my head around how to properly secure MySQL and Apache, with the mysql and www groups, plus the whole idea of adding special users and passwords for the Web server and the database. Especially for MySQL, since it has its own system of users and passwords, the whole thing is doubly confusing. I have gotten quite a few Apache security tips from Carla's "Linux Cookbook." Getting the Web server running is easy, but properly securing it, while allowing for scripts to be run and granting users the proper FTP access to update the Web site, seems to be quite difficult, to me anyway, since I'm not a trained ... anything. And right now, SQL databases continue to be completely, utterly foreign to me. I'm working on it ... One thing I'll be doing is looking for a reference on what all of the various groups in Linux actually let you do -- in detail. |
| Sander_Marechal Jun 16, 2008 12:08 PM EDT |
Apache and MySQL is usually no problem for me. Debian has it pretty well configured out-of-the-box. I still have problems on multi-user desktop machines though. Example: My girlfriend and I both use this computer. I would like to create /home/shared and set it up in such a way that anything written there by either one of us is accessible *and writable* by both of us, without continually mucking around and setting groups and write access. I can't get it working the way I want to on a single machine. The only reliable way I found so far is using an NFS network share on my server. I can configure the server in such a way that the user, group and access bits are all rewritten to something I want, and on the desktop I can mount it in such a way that it's writable for the both of us. So far, when I created Linux machines for other people (e.g. my parents) I simply create a single user account that both people use so I can avoid this issue. Any idea how I can set it up this way without using NFS? |
| Steven_Rosenber Jun 16, 2008 1:03 PM EDT |
Sander, what strikes me as a strange way to configure things out of the box, in most installations I've done, when creating more than one user account, every user has read access to every other user's /home file. Even in OpenBSD, when I create a second user, until I change permissions on all of the users' /home directories, everybody can see everything. You'd think that in OpenBSD, of all distros, that would be one of the paranoia-fueled defaults. Regarding two users being able to freely read and write to each other's home files, couldn't you set up a group for the two users and make that group the primary group for both user accounts? Then if you set the permissions for both /home directories to that group, both users would have free reign within it? The only difficulty would be setting the accounts so that new files and directories created by each user are created with the proper group, but I imagine that re-setting the primary group for the user accounts would take care of that. Mind you, I didn't try this, but it seems like it could work ... |
| Sander_Marechal Jun 16, 2008 9:10 PM EDT |
Steven: There's another problem. The default umask is 0022 which means that default rights for new files are 0644. No group write access. I can change the umask in bashrc but many applications seem to ignore the default umask. Also, umask has no effect of files copied, only on newly created files. Besides that, setting a new default group for the users and setting the umask to 0002 means that I would be able to write files in someone else's home directory as well. I want it set up in such a way that only /home/shared is writable by all. I have tried sticky bits as well and it nearly works, except of copied files. Unfortunately this happens a lot. E.g. files are downloaded or images taken from a camera, they are edited and then put in the shared directory. Perhaps running an NFS server on the local host and mounting the local share is the best way after all. There doesn't seem to be an option on Linux/unix file systems to say that all files contained in it should have a specific group and specific rights. |
| krisum Jun 17, 2008 6:17 AM EDT |
Sander, Default ACL permissions on the shared directory will *nearly* work for you and will not have any umask issues, except for the copying problem. I just checked that with default ACLs when a file is copied then even though it gets the correct permissions (as inherited from the default permissions), the ACL mask is apparently not and set to read-only. I think the reason is that when a file is copied then it will effectively do a chmod to match the permissions of the source file (e.g. if source file is 644 with no ACLs, then initially destination file will get the correct ACL permissions including the mask but then a chmod 644 on the destination file will cause the ACL mask to be recalculated) -- just tested my theory by creating source file with 664 perms and copying that set the ACL mask correctly. So, probably NFS server seems to be the way. But since we do have the source, it should be possible to patch nautilus/konqueror/... to reset ACL mask during copies. |
| Sander_Marechal Jun 17, 2008 6:26 AM EDT |
Thanks for testing that krisum. What I really can't wrap my head around is why such a common and ordinary use-case as having a directory where multiple people can read/write everything hasn't been tackled at least a decade ago. |
| krisum Jun 17, 2008 7:50 AM EDT |
I guess the question is what would be the sensible default for files copied: whether to match the source permissions as closely as possible (particularly when source does not use ACLs) or to match the permissions of the destination directory. If the source files all have ACL mask set to rw, then the copying results in desired permissions. So one solution could be to recursively turn default ACL mask to rw on all source directories from where copying could possibly be done. This would still be a problem for removable devices having UNIX filesystems where doing this is not possible (I think this should still work with devices that use FAT/NTFS if the umask in mount is liberal enough). Btw, if you will like to take this approach then I can give the commands that will do it. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!