Re: sudoers tty defaults (Re: Changing Users in a script)
Tom H wrote: > I've just re-read the sudoers man page (after a VERY long time), > thinking that it would help me "refudiate" the fact that the > "Defaults" line had some in-built, unlisted defaults, when in fact, > I've been misusing "sudo -L" for more years than I care to remember... And I see that with the latest sudo in Sid that it installs a new upstream sudo and the upstream sudo no longer has the sudo -L option. The 'sudo -L' is gone now. Bob Here is the upstream ChangeLog concerning sudo -L: 2010-05-28 Todd C. Miller * doc/sudo.cat, doc/sudo.man.in, doc/sudo.pod, src/parse_args.c, src/sudo_usage.h.in: Completely remove the -L flag from the sudo front end. [3d220030b720] 2009-12-07 Todd C. Miller * sudo.pod: The -L flag will be removed in sudo 1.7.4 [ffd026084333] 1999-10-12 Todd C. Miller * sudo.cat, sudo.html, sudo.man, sudo.pod: document -L flag [dc803e1ce0d7] 1999-09-08 Todd C. Miller Add a "-L" flag to list the name of options with their descriptions. This may only be temporary. signature.asc Description: Digital signature
Re: sudoers tty defaults (Re: Changing Users in a script)
On Tue, Aug 16, 2011 at 6:37 AM, Walter Hurry wrote: > On Mon, 15 Aug 2011 17:33:58 -0400, Tom H wrote: > >> "sudo -L" lists the full list of "Defaults". I'd be very surprised if >> even one of these isn't set. > > Then prepare for a surprise. Vanilla /etc/sudoers in Squeeze: > > # /etc/sudoers > > Defaults env_reset Thanks. The big surprised isn't that they aren't set, it's that I was talking COMPLETE rubbish - and have been using it :( - when I said that '"sudo -L" lists the full list of "Defaults"'. I've just re-read the sudoers man page (after a VERY long time), thinking that it would help me "refudiate" the fact that the "Defaults" line had some in-built, unlisted defaults, when in fact, I've been misusing "sudo -L" for more years than I care to remember... Thanks for the correction! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwZPn3kDoR4UFbmbuwY5oBvuP3=K3=+w+w8kdxuwgh...@mail.gmail.com
Re: sudoers tty defaults (Re: Changing Users in a script)
On Mon, 15 Aug 2011 17:33:58 -0400, Tom H wrote: > "sudo -L" lists the full list of "Defaults". I'd be very surprised if > even one of these isn't set. Then prepare for a surprise. Vanilla /etc/sudoers in Squeeze: # /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaultsenv_reset # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification rootALL=(ALL) ALL # Allow members of group sudo to execute any command # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j2dh8f$se7$1...@dough.gmane.org
Re: Changing Users in a script
Hal Vaughan wrote: > Bob Proulx wrote: > > There are distinct advantages to a backup push system. Not proposing > > that you change away from it. But I tend to pull backups from /home > > to the backup server. This means that whatever is in /home comes over > > whether it is associated with a user's home directory or not. All I > > manage is machines. Not machines and users. > > How is it that a pull system would get more? I didn't know there'd > be files associated with a user that are outside of their home > directory. I have backup configured to pull from a machine. Any users in /home are all backed up because /home is backed up and without any need to specifically enumerate a particular user. Add a user, their home directory will be in /home, they will get backed up automatically. It has nothing to do with files outside of a user's home directory. A pull can miss if the machine isn't up. So this isn't good for machines that are not on all of the time. But with a push system hosts that are only on some of the time can push their backup when they are up. So often a push is better. Bob signature.asc Description: Digital signature
Re: Changing Users in a script
On Aug 15, 2011, at 2:15 PM, Bob Proulx wrote: > Bob Proulx wrote: >> Hal Vaughan wrote: >>> The problem is sudo can't be run without a tty, so I can run it >>> myself, but it won't run from a script. >> >> Using 'su' would solve that problem. > > BTW... I assume that is because you have tty-tickets turned on for > sudo? In which case you could avoid it with sudo too by turning off > tty-tickets for this use case. Not dealing with that. For my two NAS units, I really want to do as little as possible. Since I need the script anyway, I'd rather just use that only. Thanks! Hal -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e895b5e-1be9-464d-b126-9fdc51617...@halblog.com
Re: Changing Users in a script
On Aug 15, 2011, at 2:05 PM, Bob Proulx wrote:
> Hal Vaughan wrote:
>> I have a system with several different users and would like to use
>> cron to run this script as root:
>>
>> #!/bin/bash
>>
>> for user in `ls /home/`; do
>> #echo "Path: $user"
>> if [ "${user:0:1}" != "0" ]; then
>> path="/home/$user/Backup"
>> if [ -e $path ]; then
>> echo "Calling backup for user: $user"
>> sudo -u $user /usr/local/bin/user-backup
>> fi
>> fi
>> done
>
> Personally if I were writing this then if the script is running as
> root then instead of using 'sudo' here I would use 'su' instead.
>
> su -c /usr/local/bin/user-backup $user
>
> Mostly because su is more traditional and "more core" than sudo and
> just seems like the better fit for the job. But it is a matter of
> taste here.
Senile moment -- I keep forgetting that I can use su for different users, too.
Thanks for the reminder!
>> The idea is that instead of adding a backup script every time I add
>> a user, this script will go through the /home directories and skip
>> any that start with a 0 (a program I'm using creates some
>> directories there, but starts their names with a 0) and
>> automatically call the generic backup script for that user.
>
> Seems reasonable so far. Also you should skip directories called
> "lost+found" in the case that /home happens to be a mount point on a
> filesystem such as ext[23] that uses lost+found.
Thanks for the reminder!
>> The problem is sudo can't be run without a tty, so I can run it
>> myself, but it won't run from a script.
>
> Using 'su' would solve that problem.
>
>> Any other way I can do this?
>
> There are distinct advantages to a backup push system. Not proposing
> that you change away from it. But I tend to pull backups from /home
> to the backup server. This means that whatever is in /home comes over
> whether it is associated with a user's home directory or not. All I
> manage is machines. Not machines and users.
How is it that a pull system would get more? I didn't know there'd be files
associated with a user that are outside of their home directory.
Hal
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/f25320a2-3441-4188-9071-c1218dc59...@halblog.com
Re: sudoers tty defaults (Re: Changing Users in a script)
On Mon, Aug 15, 2011 at 3:51 PM, Walter Hurry wrote: > On Mon, 15 Aug 2011 13:12:04 -0600, Bob Proulx wrote: >> Tom H wrote: >>> Both are set by default. >> >> Just tty_tickets is set by default. requiretty is off by default. >> >> $ man 5 sudoers >> >> tty_tickets If set, users must authenticate on a per-tty >> basis. >> With this flag enabled, sudo will use a file >> named for the tty the user is logged in on in the >> user's time stamp directory. If disabled, the >> time stamp of the directory is used instead. >> This flag is on by default. >> >> requiretty If set, sudo will only run when the user is >> logged in >> to a real tty. When this flag is set, sudo can >> only be run from a login session and not via >> other means such as cron(8) or cgi-bin scripts. >> This flag is off by default. >> >> Best would be to run 'sudo -l' and see what flags are actually set at >> the time. And remember that /etc/sudoers.d/* is a directory of >> additional snippets that are also included into the configuration. > > For what it is worth, I'm not sure that that man page is up to date. > Squeeze here (up to date), and I have done nothing directly with the > supplied /etc/sudoers; only used visudo to add myself. > > It has neither tty-tickets nor requiretty. I note by the way, that this > differs from RHEL and derivatives, which include requiretty by default. "sudo -L" lists the full list of "Defaults". I'd be very surprised if even one of these isn't set. "sudo -l" lists the commands that the invoking user can run as well whatever's explicitly set on the "Defaults" line. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Sx_piSLfC-ao92=njdsifu-ud+zjxds1wqxfdwibea...@mail.gmail.com
Re: sudoers tty defaults (Re: Changing Users in a script)
Walter Hurry wrote: > Bob Proulx wrote: > > Best would be to run 'sudo -l' and see what flags are actually set at > > the time. And remember that /etc/sudoers.d/* is a directory of > > additional snippets that are also included into the configuration. > > For what it is worth, I'm not sure that that man page is up to date. > Squeeze here (up to date), and I have done nothing directly with the > supplied /etc/sudoers; only used visudo to add myself. > > It has neither tty-tickets nor requiretty. I agree. The man apge is out of sync. My bad for quoting it without checking it. After checking various releases I concur that neither of those are set by default on Debian. > I note by the way, that this differs from RHEL and derivatives, > which include requiretty by default. Yep. Bob signature.asc Description: Digital signature
Re: sudoers tty defaults (Re: Changing Users in a script)
On Mon, 15 Aug 2011 13:12:04 -0600, Bob Proulx wrote: > Tom H wrote: >> Both are set by default. > > Just tty_tickets is set by default. requiretty is off by default. > > $ man 5 sudoers > >tty_tickets If set, users must authenticate on a per-tty >basis. >With this flag enabled, sudo will use a file >named for the tty the user is logged in on in the >user's time stamp directory. If disabled, the >time stamp of the directory is used instead. >This flag is on by default. > >requiretty If set, sudo will only run when the user is >logged in >to a real tty. When this flag is set, sudo can >only be run from a login session and not via >other means such as cron(8) or cgi-bin scripts. >This flag is off by default. > > Best would be to run 'sudo -l' and see what flags are actually set at > the time. And remember that /etc/sudoers.d/* is a directory of > additional snippets that are also included into the configuration. For what it is worth, I'm not sure that that man page is up to date. Squeeze here (up to date), and I have done nothing directly with the supplied /etc/sudoers; only used visudo to add myself. It has neither tty-tickets nor requiretty. I note by the way, that this differs from RHEL and derivatives, which include requiretty by default. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j2btcu$mt$1...@dough.gmane.org
sudoers tty defaults (Re: Changing Users in a script)
Tom H wrote: > Both are set by default. Just tty_tickets is set by default. requiretty is off by default. $ man 5 sudoers tty_tickets If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will use a file named for the tty the user is logged in on in the user's time stamp directory. If disabled, the time stamp of the directory is used instead. This flag is on by default. requiretty If set, sudo will only run when the user is logged in to a real tty. When this flag is set, sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin scripts. This flag is off by default. Best would be to run 'sudo -l' and see what flags are actually set at the time. And remember that /etc/sudoers.d/* is a directory of additional snippets that are also included into the configuration. $ sudo -l Bob signature.asc Description: Digital signature
Re: Changing Users in a script
On Mon, Aug 15, 2011 at 2:39 PM, Bob Proulx wrote: > Tom H wrote: >> Bob Proulx wrote: >>> >>> BTW... I assume that is because you have tty-tickets turned on for >>> sudo? In which case you could avoid it with sudo too by turning off >>> tty-tickets for this use case. >> >> I think that you're confusing "tty-tickets" with "requiretty". > > Ah... Likely. I am not using either one. Both are set by default. tty-tickets --> require per tty password entry !tty-tickets --> as long as the sudo timestamp hasn't timed out, you can use sudo on a 2nd/3rd/... tty without entering a password -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sw2mxxgqmo0gymdxb65rlvxdo1cv+4ug-uu2md+nbm...@mail.gmail.com
Re: Changing Users in a script
Tom H wrote: > Bob Proulx wrote: > > BTW... I assume that is because you have tty-tickets turned on for > > sudo? In which case you could avoid it with sudo too by turning off > > tty-tickets for this use case. > > I think that you're confusing "tty-tickets" with "requiretty". Ah... Likely. I am not using either one. Thanks! Bob signature.asc Description: Digital signature
Re: Changing Users in a script
On Mon, Aug 15, 2011 at 2:15 PM, Bob Proulx wrote: > Bob Proulx wrote: >> Hal Vaughan wrote: >> > The problem is sudo can't be run without a tty, so I can run it >> > myself, but it won't run from a script. >> >> Using 'su' would solve that problem. > > BTW... I assume that is because you have tty-tickets turned on for > sudo? In which case you could avoid it with sudo too by turning off > tty-tickets for this use case. I think that you're confusing "tty-tickets" with "requiretty". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sxsgb29bx1rv-5qvhh2snm4m12jo8g3e0upzngeazf...@mail.gmail.com
Re: Changing Users in a script
Bob Proulx wrote: > Hal Vaughan wrote: > > The problem is sudo can't be run without a tty, so I can run it > > myself, but it won't run from a script. > > Using 'su' would solve that problem. BTW... I assume that is because you have tty-tickets turned on for sudo? In which case you could avoid it with sudo too by turning off tty-tickets for this use case. Bob signature.asc Description: Digital signature
Re: Changing Users in a script
Hal Vaughan wrote:
> I have a system with several different users and would like to use
> cron to run this script as root:
>
> #!/bin/bash
>
> for user in `ls /home/`; do
> # echo "Path: $user"
> if [ "${user:0:1}" != "0" ]; then
> path="/home/$user/Backup"
> if [ -e $path ]; then
> echo "Calling backup for user: $user"
> sudo -u $user /usr/local/bin/user-backup
> fi
> fi
> done
Personally if I were writing this then if the script is running as
root then instead of using 'sudo' here I would use 'su' instead.
su -c /usr/local/bin/user-backup $user
Mostly because su is more traditional and "more core" than sudo and
just seems like the better fit for the job. But it is a matter of
taste here.
> The idea is that instead of adding a backup script every time I add
> a user, this script will go through the /home directories and skip
> any that start with a 0 (a program I'm using creates some
> directories there, but starts their names with a 0) and
> automatically call the generic backup script for that user.
Seems reasonable so far. Also you should skip directories called
"lost+found" in the case that /home happens to be a mount point on a
filesystem such as ext[23] that uses lost+found.
> The problem is sudo can't be run without a tty, so I can run it
> myself, but it won't run from a script.
Using 'su' would solve that problem.
> Any other way I can do this?
There are distinct advantages to a backup push system. Not proposing
that you change away from it. But I tend to pull backups from /home
to the backup server. This means that whatever is in /home comes over
whether it is associated with a user's home directory or not. All I
manage is machines. Not machines and users.
Bob
signature.asc
Description: Digital signature
Changing Users in a script
I have a system with several different users and would like to use cron to run
this script as root:
#!/bin/bash
for user in `ls /home/`; do
# echo "Path: $user"
if [ "${user:0:1}" != "0" ]; then
path="/home/$user/Backup"
if [ -e $path ]; then
echo "Calling backup for user: $user"
sudo -u $user /usr/local/bin/user-backup
fi
fi
done
The idea is that instead of adding a backup script every time I add a user,
this script will go through the /home directories and skip any that start with
a 0 (a program I'm using creates some directories there, but starts their names
with a 0) and automatically call the generic backup script for that user.
The problem is sudo can't be run without a tty, so I can run it myself, but it
won't run from a script.
I want the backup script to run under each user's name to match the user on the
backup system.
Are there other ways to do this with an "all-in-one" approach? Either for a
script run as root to run scripts with the id of the users or some generic way
to tell cron to run a script once for each user that meets certain conditions?
I prefer the all-in-one solutions, since when I add a user, I'm adding it to
their system, to this backup NAS, and to an offsite backup NAS, and even though
I use notes, it's easy to forget having to do extra things when adding a user.
So I'd really prefer a solution that handles all of them at once.
Any other way I can do this?
Thanks!
Hal
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/6f014e0d-554d-449c-8a28-0e989a86d...@halblog.com
