This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: csih-0.1.7-1


On Aug 21 23:11, Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
> >> There are actually two questions: (a) should csih_check_access be
> >> checking that the Administrators group has the desired access?, and (b)
> >> are extended ACLs *actually* masked by the "other" bits?
> > 
> > a) Actually, since all file access is using backup privileges,
> >    administrators typically have access anyway.  But we don't know if
> >    admins on a given installation actually *have* backup privileges,
> >    given that you can remove them from any account.
> 
> I'm not sure I follow. Are you talking about
>   1) setup (current)
>   2) setup-1.7

Why setup?  This is a helper script for an existing installation.

>   3) cygwin-1.5
>       a) when user is a member of the administrators group
>       B) else?
>   4) cygwin-1.7
>       a) when user is a member of the administrators group
>       b) else?

I'm talking about Cygwin.  Cygwin 1.5 has a still a few restrictions in
terms of administrator access (no chdir into a dir with no admins
access), Cygwin 1.7 does not have these restrictions.

> I mean, take case 3b or 4b: if a regular joe user does not HAVE backup
> privilege, how can "all file access [be] using backup privileges" which
> joe user doesn't have?

It doesn't.  Maybe I'm missing something but I thought we're talking about
the access of the administrators group, not the access of joe user.  You're
testing admins access.  I say, Cygwin switches on backup permissions (if
they exist) and opens all files with backup intent.  For joe user, nothing
changes.  The admins group OTOH, which by default *has* backup permissions,
can now access files and directories like any other BOFH.  That's why the
permissions of admins and SYSTEM are not as important anymore as they were
in earlier versions of Cygwin.

> >  So, I think the test makes still sense, sort of. From a educational perspective at
> >    least :)
> 
> OK.
> 
> > b) No.  ACCESS_ALLOW_ACEs permissions in the DACL are additive.
> 
> And that's what I was really looking for. So this test (and comments):
> 
> # the desired permissions. However, extended ACL entries are masked by
> # the chmod bits for other, so we have to check that 'other' ALSO has at
> # least the desired permissions. Otherwise, notify.
> [ -z "$(echo "$ls_result" | sed -n /^......."$perm"/p)" ] && notify=1
> 
> can go away.
> 
> However, while fixing this, I found that many of the checks in
> csih_check_access were not coded properly:
> 
> if [ shell_fun_call -a $var -eq "foo" ]
> 
> doesn't work.  It should be
> 
> if ( shell_fun_call && [ $var -eq "foo" ])
> 
> So, I fixed that, too -- although I dislike the extra subshells.

See Eric's comments.  Especially the $var -eg "foo" is probably not
a good idea.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]