group permissions on directory being ignored for group member

[Joel Rees]

On Sat, Jul 18, 2015 at 5:41 PM, blind Pete <0123peter at gmail.com> wrote:
> Itamar Gal wrote:
>
>> Hey Ubuntu users,
>>
>> Some quick background about me. I'm a junior sysadmin in a firm whose IT
>> department has no senior sysadmins, and I'm relatively new to the job.
>> I've inherited an environment from a previous administrator who was much
>> better at his job than I am, but who didn't leave much in the way of
>> documentation.

I wouldn't say he was that much better if he failed to document his
work. Documentation is a base-level requirement of sysadmin, although
some technically skilled sysads deliberately de-prioritize
documentation in an attempt to strengthen job security.

On the other hand, management might be partly to blame. Lack of a
senior sysadmin could be an indication.

>> Recently we've been experiencing a seemingly bizarre issue where it seems
>> that there is a user (on an Ubuntu 12.04.4 server) who is unable to access
>> a shared directory, even though that user belongs to the group which owns
>> the directory. Here is an example session:
>>
>> $ whoami
>> username
>
> Adam, Betty, Charlie, might be easier to read,
> or even user1, user2, group1, group2.
>
>> $ cd /shared_directory
>> bash: cd: /shared_directory: Permission denied
>>
>> ls /directory
>> ls: cannot open directory /shared_directory: Permission denied
>>
>> $ ls -ld /shared_directory
>> drwxrws---+ 116 root groupname 4096 Jun 11 11:35 /shared_directory
>
> Set group id when reading the directory?

If I'm interpreting the man entry for chmod correctly, that would mean
that newly created files get the group that the directory is owned by
rather than the file creator's primary group.

> What does the plus mean?  ACL is involved?

   http://unix.stackexchange.com/questions/103114/what-do-the-fields-in-ls-al-output-mean

> "man chmod" for as start, but I don't think it will tell you enough.
> "man attr" might help.

Of man chattr

> There is a Gnome application called "Eiciel" for manipulating
> ACL's and extended user attributes, but I have not used it.
>
>> $ getent group groupname
>> groupname:*:username:otheruser
>>
>> sudo adduser username groupname
>> The user `username' is already a member of `groupname'
>>
>> I posted this question on ServerFault here:
>>
>> http://serverfault.com/questions/705988/group-permissions-on-directory-being-ignored-for-user
>>
>> but I haven't gotten any responses.
>>
>> A few remarks are probably in order. We are using LDAP-based
>> authentication which inherits from a global LDAP server run outside of our
>> department. We have a script which imports user data from the global LDAP
>> server to our own LDAP server.
>>
>> This permissions issue has happened a handful of times so far. Each time I
>> was able to fix the problem by manually removing the user account form our
>> LDAP server and then reimporting the account from the global server
>> (although I have no idea why this had any effect, as I couldn't see any
>> differences in the relevant LDAP entries). But now I've run into a case
>> where doing this didn't resolve the problem, so I probably have to figure
>> what's actually going on.
>>
>> If anyone can shed any light on this I would be forever indebted to you,
>> as I am completely baffled by this.
>>
>> Cheers,
>> Itamar
> --
> blind Pete
> Sig goes here...

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html