A ps to the perms msg

[Gene Heskett]

On Thursday 12 July 2012 18:08:02 PleegWat did opine:

> On 07/12/2012 10:10 PM, Colin Law wrote:
> > On 12 July 2012 18:14, Gene Heskett <gheskett at wdtv.com> wrote:
> >> On Thursday 12 July 2012 13:07:22 Colin Law did opine:
> >>> On 12 July 2012 15:40, Gene Heskett <gheskett at wdtv.com> wrote:
> >>>> Greets all;
> >>>> 
> >>>> I just changed /var/spool/cron/crontabs/gene so its owned by
> >>>> me again, but I am still being denied crontab -e permissions.
> >>>> Probably because /var/spool/cron/crontabs is also owned by
> >>>> root:root.  But since that directory contains ALL the
> >>>> crontabs, I can't just willy nilly change that to, so I am
> >>>> reduced to scratching my thinning hair and muttering WTF?
> >>> 
> >>> On mine, /var/spool/cron/crontabs/<user> is owned by <user> but
> >>> group crontab.  Try crontab for the group if you have not
> >>> already done that. the crontabs folder is owned by
> >>> root:crontab.
> >> 
> >> Thank you, now I can edit it.  But looking in that directory, is
> >> not root supposed to have a system stuff file there, something to
> >> run logrotate for example?  Mine seems like it is the only one
> >> there. ??
> > 
> > There is nothing in mine except the ordinary users.  I don't know
> > how it does logrotate and so on.
> 
> This is done by anacron instead. Anacron has the ability to 'catch up'
> on tasks that were scheduled while your PC was offline, which is
> especially useful on  desktop machines.
> 
> >> Also, I am not a member of the crontab group in /etc/group.  That
> >> also seems strange since I am the only meat & bones composed
> >> user, with sudo rights on the machine.  Stranger and stranger
> >> this rootless ubuntu is becoming.
> > 
> > I am not a member of crontab either, so again I don't know how it
> > works.  No doubt someone more knowledgeable will elucidate
> > ........
> 
> It works here, and I'm also not in the crontab group. The magic is
> that /usr/bin/crontab is owned by root:crontab and has the setgid bit
> set. That means that, when you are using that binary, that binary can
> use the permissions of the crontab group even though you are not
> ordinarily a member of it.
> 
> /var/spool/cron/crontab also has some interesting permissions: It has
> group write but not group read. That means that, even as the crontab
> group, you cannot list the files in that directory, but you can create
> files. It also has the sticky bit set, which means that you can only
> delete files in that directory if you own them (rather than being able
> to delete any file in that directory).
> 
> PleegWat

Thanks for that explanation, you obviously are a heck of a lot better 
versed in this than I. It ought to be in a man page on perms!  Hint hint. 
:)

I've been linux only since RH5 in about '98.  And of course I'm an old fart 
(77) whose memory seems to get shorter by the day.
  
Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
	"For I perceive that behind this seemingly unrelated sequence
of events, there lurks a singular, sinister attitude of mind."
	"Whose?"
	"MINE! HA-HA!"