group permissions on directory being ignored for group member

[Itamar Gal]

Hey Joel,

Thanks for your response.

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.
>

I think it's mostly due to lack of resources. The department is only a few
years old, and they're still in the process of building their IT department.

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.
>

Yes, that's correct. This is because the directory is supposed to function
as a shared directory.

Cheers,
Itamar

On Sat, Jul 18, 2015 at 5:59 AM, Joel Rees <joel.rees at gmail.com> wrote:

> 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
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20150718/5c4760e5/attachment.html>