Re: issue with unsetting 'arch' flag
On Wednesday 06 October 2010 00:50:54 Alexander Best wrote: > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. > ^^non-root ^^root^^non-root > > chflags claims to have cleared the 'arch' flag (which should be impossible > as non-root user), but indeed has done nothing. I guess that should be "sudo chflags arch ftest"? -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
Den 06/10/2010 kl. 08.00 skrev Tim Kientzle: > > That's the timestamp on the pseudo-entry used to store the archive > symbol table. (GNU/SysV ar files use a pseudo-entry named "/" to > store the symbol table. Since '/' is added to end of names in this > format, this is essentially an entry with an empty name.) > > The current ar code generates this entry and sets the timestamp > around line 624 of usr.bin/ar/write.c. > > As far as I can tell, ar itself doesn't care about the timestamp here; > it's possible that ranlib or ld do care. If they don't, we could set > this timestamp to zero always. Yeah, I had a look at the code too. I was thinking maybe it would help to add a modifier to replace timestamps, uids and gids with '0' when inserting a file, to respect POLA. Thanks, Erik
Re: Timestamps in static libraries
Erik Cederstrand wrote: > It seems I can at least normalize the .a files using something > like the following to weed out timestamps and uid/gid: > > % ar -x /usr/lib/libfetch.a > % chown 0:0 * > % touch -t 19700101 * > % ar -r libfetch.a `ar -t /usr/lib/libfetch.a` > > ... Unfortunately it seems there's still a creation time of the > archive itself that I cant alter using the above, so the md5 sums > still don't match: > > % diff mod.strings orig.strings > 2c2 > < / 1286312209 0 0 0 958 ` > --- > > / 1269146263 0 0 0 958 ` Any particular reason to recollect them into an archive, if the point is just to check md5 signatures? I'm pretty sure collecting them with tar instead will avoid this problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
Den 06/10/2010 kl. 10.06 skrev per...@pluto.rain.com: > Erik Cederstrand wrote: > >> It seems I can at least normalize the .a files using something >> like the following to weed out timestamps and uid/gid: >> >> % ar -x /usr/lib/libfetch.a >> % chown 0:0 * >> % touch -t 19700101 * >> % ar -r libfetch.a `ar -t /usr/lib/libfetch.a` >> >> ... Unfortunately it seems there's still a creation time of the >> archive itself that I cant alter using the above, so the md5 sums >> still don't match: >> >> % diff mod.strings orig.strings >> 2c2 >> < / 1286312209 0 0 0 958 ` >> --- >>> / 1269146263 0 0 0 958 ` > > Any particular reason to recollect them into an archive, if the > point is just to check md5 signatures? I'm pretty sure collecting > them with tar instead will avoid this problem. That's of course another option. I could unpack the archive and be satisfied if all contained files have matching md5's. I guess the perfectionist in me is protesting. If I build FreeBSD twice from the same source code, the result should be exactly the same. It would be useful in a number of cases, e.g. IDS. ccache also relies on the assumption that checksums will match on identical source code and compiler version, although I know that's a level beneath where ar operates. Thanks, Erik
Re: Timestamps in static libraries
Den 06/10/2010 kl. 08.00 skrev Tim Kientzle:
>>
>> % diff mod.strings orig.strings
>> 2c2
>> < / 1286312209 0 0 0 958 `
>> ---
>>> / 1269146263 0 0 0 958 `
>
> That's the timestamp on the pseudo-entry used to store the archive
> symbol table. (GNU/SysV ar files use a pseudo-entry named "/" to
> store the symbol table. Since '/' is added to end of names in this
> format, this is essentially an entry with an empty name.)
>
> The current ar code generates this entry and sets the timestamp
> around line 624 of usr.bin/ar/write.c.
>
> As far as I can tell, ar itself doesn't care about the timestamp here;
> it's possible that ranlib or ld do care. If they don't, we could set
> this timestamp to zero always.
Is something like the following acceptable? Without risking changes to
buildworld/distribution just now, this would allow me to dump contents of an
archive and re-insert them with '0' for mtime, uid and gid before checking
checksums, without affecting normal ar behaviour.
erik% svn diff
Index: ar.1
===
--- ar.1(revision 213478)
+++ ar.1(working copy)
@@ -62,6 +62,7 @@
.Op Fl a Ar position-after
.Op Fl b Ar position-before
.Op Fl c
+.Op Fl D
.Op Fl i Ar position-before
.Op Fl j
.Op Fl s
@@ -179,6 +180,14 @@
.Ar archive .
The archive's symbol table, if present, is updated to reflect
the new contents of the archive.
+.It Fl D
+When used in combination with the
+.Fl r
+option, insterts 0's instead of the real mtime, uid and gid values
+from the members named by arguments
+.Ar files ... .
+This ensures that checksums on the resulting archives are reproducible
+when member contents are identical.
.It Fl f
Synonymous with option
.Fl T .
Index: ar.c
===
--- ar.c(revision 213478)
+++ ar.c(working copy)
@@ -154,7 +154,7 @@
}
}
- while ((opt = getopt_long(argc, argv, "abCcdfijlMmopqrSsTtuVvxz",
+ while ((opt = getopt_long(argc, argv, "abCcdDfijlMmopqrSsTtuVvxz",
longopts, NULL)) != -1) {
switch(opt) {
case 'a':
@@ -173,6 +173,9 @@
case 'd':
set_mode(bsdar, opt);
break;
+ case 'D':
+ bsdar->options |= AR_D;
+ break;
case 'f':
case 'T':
bsdar->options |= AR_TR;
@@ -357,8 +360,8 @@
(void)fprintf(stderr, "\tar -m [-Tabijsvz] position archive file
...\n");
(void)fprintf(stderr, "\tar -p [-Tv] archive [file ...]\n");
(void)fprintf(stderr, "\tar -q [-Tcjsvz] archive file ...\n");
- (void)fprintf(stderr, "\tar -r [-Tcjsuvz] archive file ...\n");
- (void)fprintf(stderr, "\tar -r [-Tabcijsuvz] position archive file
...\n");
+ (void)fprintf(stderr, "\tar -r [-TcDjsuvz] archive file ...\n");
+ (void)fprintf(stderr, "\tar -r [-TabcDijsuvz] position archive file
...\n");
(void)fprintf(stderr, "\tar -s [-jz] archive\n");
(void)fprintf(stderr, "\tar -t [-Tv] archive [file ...]\n");
(void)fprintf(stderr, "\tar -x [-CTouv] archive [file ...]\n");
Index: ar.h
===
--- ar.h(revision 213478)
+++ ar.h(working copy)
@@ -43,6 +43,7 @@
#define AR_U 0x0200 /* only extract or update newer members.*/
#define AR_V 0x0400 /* verbose mode */
#define AR_Z 0x0800 /* gzip compression */
+#define AR_D 0x1000 /* insert members with dummy mtime, uid and gid
*/
#define DEF_BLKSZ 10240/* default block size */
Index: write.c
===
--- write.c (revision 213478)
+++ write.c (working copy)
@@ -163,11 +163,22 @@
if (mtime != 0 && bsdar->options & AR_U && sb.st_mtime <= mtime)
goto giveup;
- obj->uid = sb.st_uid;
- obj->gid = sb.st_gid;
+ /*
+* When modifier -D is specified, mtime and UID / GID from the file
+* will be replaced with 0. This ensures that checksums will match
+* for two archives containing the exact same files.
+ */
+ if (bsdar->options & AR_D) {
+ obj->uid = 0;
+ obj->gid = 0;
+ obj->mtime = 0;
+ } else {
+ obj->uid = sb.st_uid;
+ obj->gid = sb.st_gid;
+ obj->mtime = sb.st_mtime;
+ }
obj->md = sb.st_mode;
obj->size = sb.st_size;
- obj->mtime = sb.st_mtime;
obj->dev = sb.st_dev;
obj->ino = sb.st_ino;
@@ -621,7 +632,10 @@
bsdar->options & AR_S) {
entry = archive_entry_new();
archive_entry_copy_pathna
Re: Timestamps in static libraries
Den 06/10/2010 kl. 13.07 skrev Erik Cederstrand:
> Is something like the following acceptable? Without risking changes to
> buildworld/distribution just now, this would allow me to dump contents of an
> archive and re-insert them with '0' for mtime, uid and gid before checking
> checksums, without affecting normal ar behaviour.
Great, I didn't even see the discussion on this list recently:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-September/033005.html
Anyway, I added file mode to the patch. Apparently recent binutils also added
this feature. I haven't looked at their patch, but chance has it I used the
same option '-D'.
I'm sure the file mode I'm setting in line 175 of write.c is wrong (obj->md =
100644), but I couldn't quite figure out how to set the value to rw-r--r--.
Here's the new patch:
Index: ar.1
===
--- ar.1(revision 213478)
+++ ar.1(working copy)
@@ -62,6 +62,7 @@
.Op Fl a Ar position-after
.Op Fl b Ar position-before
.Op Fl c
+.Op Fl D
.Op Fl i Ar position-before
.Op Fl j
.Op Fl s
@@ -179,6 +180,14 @@
.Ar archive .
The archive's symbol table, if present, is updated to reflect
the new contents of the archive.
+.It Fl D
+When used in combination with the
+.Fl r
+option, insterts 0's instead of the real mtime, uid and gid values
+and 644 instead of file mode from the members named by arguments
+.Ar files ... .
+This ensures that checksums on the resulting archives are reproducible
+when member contents are identical.
.It Fl f
Synonymous with option
.Fl T .
Index: ar.c
===
--- ar.c(revision 213478)
+++ ar.c(working copy)
@@ -154,7 +154,7 @@
}
}
- while ((opt = getopt_long(argc, argv, "abCcdfijlMmopqrSsTtuVvxz",
+ while ((opt = getopt_long(argc, argv, "abCcdDfijlMmopqrSsTtuVvxz",
longopts, NULL)) != -1) {
switch(opt) {
case 'a':
@@ -173,6 +173,9 @@
case 'd':
set_mode(bsdar, opt);
break;
+ case 'D':
+ bsdar->options |= AR_D;
+ break;
case 'f':
case 'T':
bsdar->options |= AR_TR;
@@ -357,8 +360,8 @@
(void)fprintf(stderr, "\tar -m [-Tabijsvz] position archive file
...\n");
(void)fprintf(stderr, "\tar -p [-Tv] archive [file ...]\n");
(void)fprintf(stderr, "\tar -q [-Tcjsvz] archive file ...\n");
- (void)fprintf(stderr, "\tar -r [-Tcjsuvz] archive file ...\n");
- (void)fprintf(stderr, "\tar -r [-Tabcijsuvz] position archive file
...\n");
+ (void)fprintf(stderr, "\tar -r [-TcDjsuvz] archive file ...\n");
+ (void)fprintf(stderr, "\tar -r [-TabcDijsuvz] position archive file
...\n");
(void)fprintf(stderr, "\tar -s [-jz] archive\n");
(void)fprintf(stderr, "\tar -t [-Tv] archive [file ...]\n");
(void)fprintf(stderr, "\tar -x [-CTouv] archive [file ...]\n");
Index: ar.h
===
--- ar.h(revision 213478)
+++ ar.h(working copy)
@@ -43,6 +43,7 @@
#define AR_U 0x0200 /* only extract or update newer members.*/
#define AR_V 0x0400 /* verbose mode */
#define AR_Z 0x0800 /* gzip compression */
+#define AR_D 0x1000 /* insert members with dummy mode, mtime, uid
and gid */
#define DEF_BLKSZ 10240/* default block size */
Index: write.c
===
--- write.c (revision 213478)
+++ write.c (working copy)
@@ -163,11 +163,23 @@
if (mtime != 0 && bsdar->options & AR_U && sb.st_mtime <= mtime)
goto giveup;
- obj->uid = sb.st_uid;
- obj->gid = sb.st_gid;
- obj->md = sb.st_mode;
+ /*
+* When option '-D' is specified, mtime and UID / GID from the file
+* will be replaced with 0, and file mode with 644. This ensures that
+* checksums will match for two archives containing the exact same
files.
+ */
+ if (bsdar->options & AR_D) {
+ obj->uid = 0;
+ obj->gid = 0;
+ obj->mtime = 0;
+ obj->md = 100644;
+ } else {
+ obj->uid = sb.st_uid;
+ obj->gid = sb.st_gid;
+ obj->mtime = sb.st_mtime;
+ obj->md = sb.st_mode;
+ }
obj->size = sb.st_size;
- obj->mtime = sb.st_mtime;
obj->dev = sb.st_dev;
obj->ino = sb.st_ino;
@@ -621,7 +633,10 @@
bsdar->options & AR_S) {
entry = archive_entry_new();
archive_entry_copy_pathname(entry, "/");
- archive_entry_set_mtime(entry, time(NULL), 0);
+ if (bsdar->options & A
Re: issue with unsetting 'arch' flag
On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best wrote: > hi there, > > i think the following example shows the problem better than a long > explanation: > > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. > ^^non-root ^^root ^^non-root > > chflags claims to have cleared the 'arch' flag (which should be impossible as > non-root user), but indeed has done nothing. > > i've tried the same with 'sappnd' and that works as can be expected. > > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, jpaetzel) > and stable/7 (nox). > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with EPERM. Fails for me when I call the syscall directly, as I would expect, and passes when I'm superuser: $ ./test_chflags (uid, euid) = (1000, 1000) test_chflags: chflags: Operation not permitted test_chflags: lchflags: Operation not permitted $ sudo ./test_chflags (uid, euid) = (0, 0) According to my basic inspection in strtofflags (.../lib/libc/gen/strtofflags.c), it works as well. And last but not least, executing the commands directly on the CLI work: $ tmpfile=`mktemp /tmp/chflags.XX` $ chflags arch $tmpfile chflags: /tmp/chflags.nQm1IL: Operation not permitted $ rm $tmpfile $ tmpfile=`mktemp /tmp/chflags.XX` $ sudo chflags arch $tmpfile $ sudo chflags noarch $tmpfile $ rm $tmpfile Your results may (but shouldn't) vary [unless your environment is setup differently]... Please note that I'm using UFS2 with SUJ... not all filesystems support this (ext2/3/4? msdosfs? ZFS?), so I would be careful about which filesystem you pick and whether or not there's a bug where it's not properly identifying that the operation you're attempting to perform is valid. Thanks, -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 test_chflags.c Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed Oct 6 10, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best wrote: > > hi there, > > > > i think the following example shows the problem better than a long > > explanation: > > > > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. > > ^^non-root ^^root ^^non-root > > > > chflags claims to have cleared the 'arch' flag (which should be impossible > > as > > non-root user), but indeed has done nothing. > > > > i've tried the same with 'sappnd' and that works as can be expected. > > > > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, > > jpaetzel) > > and stable/7 (nox). > > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with EPERM. > > Fails for me when I call the syscall directly, as I would expect, > and passes when I'm superuser: > > $ ./test_chflags > (uid, euid) = (1000, 1000) > test_chflags: chflags: Operation not permitted > test_chflags: lchflags: Operation not permitted > $ sudo ./test_chflags > (uid, euid) = (0, 0) > > According to my basic inspection in strtofflags > (.../lib/libc/gen/strtofflags.c), it works as well. > And last but not least, executing the commands directly on the CLI work: > > $ tmpfile=`mktemp /tmp/chflags.XX` > $ chflags arch $tmpfile > chflags: /tmp/chflags.nQm1IL: Operation not permitted > $ rm $tmpfile > $ tmpfile=`mktemp /tmp/chflags.XX` > $ sudo chflags arch $tmpfile > $ sudo chflags noarch $tmpfile > $ rm $tmpfile thanks for your test app and helping out with this problem. i'm not sure however you understood the problem. probably i didn't explain it right: $ sudo rm -d /tmp/chflags.XX $ tmpfile=`mktemp /tmp/chflags.XX` $ sudo chflags arch $tmpfile $ chflags noarch $tmpfile is what's causing the problem. the last chflags call should fail, but it doesn't. cheers. alex > > Your results may (but shouldn't) vary [unless your environment is > setup differently]... > Please note that I'm using UFS2 with SUJ... not all filesystems > support this (ext2/3/4? msdosfs? ZFS?), so I would be careful about > which filesystem you pick and whether or not there's a bug where it's > not properly identifying that the operation you're attempting to > perform is valid. > Thanks, > -Garrett > > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best wrote: >> > hi there, >> > >> > i think the following example shows the problem better than a long >> > explanation: >> > >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> > ^^non-root ^^root ^^non-root >> > >> > chflags claims to have cleared the 'arch' flag (which should be impossible >> > as >> > non-root user), but indeed has done nothing. >> > >> > i've tried the same with 'sappnd' and that works as can be expected. >> > >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, >> > jpaetzel) >> > and stable/7 (nox). >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with >> > EPERM. >> >> Fails for me when I call the syscall directly, as I would expect, >> and passes when I'm superuser: >> >> $ ./test_chflags >> (uid, euid) = (1000, 1000) >> test_chflags: chflags: Operation not permitted >> test_chflags: lchflags: Operation not permitted >> $ sudo ./test_chflags >> (uid, euid) = (0, 0) >> >> According to my basic inspection in strtofflags >> (.../lib/libc/gen/strtofflags.c), it works as well. >> And last but not least, executing the commands directly on the CLI work: >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> $ rm $tmpfile >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ sudo chflags arch $tmpfile >> $ sudo chflags noarch $tmpfile >> $ rm $tmpfile > > thanks for your test app and helping out with this problem. i'm not sure > however you understood the problem. probably i didn't explain it right: > > $ sudo rm -d /tmp/chflags.XX > $ tmpfile=`mktemp /tmp/chflags.XX` > $ sudo chflags arch $tmpfile > $ chflags noarch $tmpfile > > is what's causing the problem. the last chflags call should fail, but it > doesn't. Sorry... my CLI based example was stupid. I meant: $ tmpfile=`mktemp /tmp/chflags.XX` $ chflags arch $tmpfile chflags: /tmp/chflags.V2NpXR: Operation not permitted $ chflags noarch $tmpfile $ rm $tmpfile Currently chflags(2) states: The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may only be set or unset by the super-user. Attempts to set these flags by non- super-users are rejected, >>> attempts by non-superusers to clear flags that are already unset are silently ignored. <<< These flags may be set at any time, but normally may only be unset when the system is in single-user mode. (See init(8) for details.) So this behavior is already well documented :). The EPERM section should really note SF_ARCHIVED though (whoever added the flag forgot to add that particular item to the ERRORS section). >> Your results may (but shouldn't) vary [unless your environment is >> setup differently]... >> Please note that I'm using UFS2 with SUJ... not all filesystems >> support this (ext2/3/4? msdosfs? ZFS?), so I would be careful about >> which filesystem you pick and whether or not there's a bug where it's >> not properly identifying that the operation you're attempting to >> perform is valid. >> Thanks, >> -Garrett >> >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >> Thu Aug 19 22:50:36 PDT 2010 >> r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed Oct 6 10, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > > On Wed Oct 6 10, Garrett Cooper wrote: > >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best wrote: > >> > hi there, > >> > > >> > i think the following example shows the problem better than a long > >> > explanation: > >> > > >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. > >> > ^^non-root ^^root ^^non-root > >> > > >> > chflags claims to have cleared the 'arch' flag (which should be > >> > impossible as > >> > non-root user), but indeed has done nothing. > >> > > >> > i've tried the same with 'sappnd' and that works as can be expected. > >> > > >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, > >> > jpaetzel) > >> > and stable/7 (nox). > >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with > >> > EPERM. > >> > >> Fails for me when I call the syscall directly, as I would expect, > >> and passes when I'm superuser: > >> > >> $ ./test_chflags > >> (uid, euid) = (1000, 1000) > >> test_chflags: chflags: Operation not permitted > >> test_chflags: lchflags: Operation not permitted > >> $ sudo ./test_chflags > >> (uid, euid) = (0, 0) > >> > >> According to my basic inspection in strtofflags > >> (.../lib/libc/gen/strtofflags.c), it works as well. > >> And last but not least, executing the commands directly on the CLI > >> work: > >> > >> $ tmpfile=`mktemp /tmp/chflags.XX` > >> $ chflags arch $tmpfile > >> chflags: /tmp/chflags.nQm1IL: Operation not permitted > >> $ rm $tmpfile > >> $ tmpfile=`mktemp /tmp/chflags.XX` > >> $ sudo chflags arch $tmpfile > >> $ sudo chflags noarch $tmpfile > >> $ rm $tmpfile > > > > thanks for your test app and helping out with this problem. i'm not sure > > however you understood the problem. probably i didn't explain it right: > > > > $ sudo rm -d /tmp/chflags.XX > > $ tmpfile=`mktemp /tmp/chflags.XX` > > $ sudo chflags arch $tmpfile > > $ chflags noarch $tmpfile > > > > is what's causing the problem. the last chflags call should fail, but it > > doesn't. > > Sorry... my CLI based example was stupid. I meant: > > $ tmpfile=`mktemp /tmp/chflags.XX` > $ chflags arch $tmpfile > chflags: /tmp/chflags.V2NpXR: Operation not permitted > $ chflags noarch $tmpfile > $ rm $tmpfile > > Currently chflags(2) states: > > The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may only > be set or unset by the super-user. Attempts to set these flags by non- > super-users are rejected, >>> attempts by non-superusers to clear > flags that > are already unset are silently ignored. <<< These flags may be set at > any > time, but normally may only be unset when the system is in single-user > mode. (See init(8) for details.) > > So this behavior is already well documented :). The EPERM section > should really note SF_ARCHIVED though (whoever added the flag forgot > to add that particular item to the ERRORS section). that's perfectly alright. clearing an unset flag shouldn't cause any error to be returned. however in my example arch *does* get set and still trying to unset it as normal user doesn't return an error. please make sure to *only* run the first chflags instance as root. all other command must be run as normal user. > > >> Your results may (but shouldn't) vary [unless your environment is > >> setup differently]... > >> Please note that I'm using UFS2 with SUJ... not all filesystems > >> support this (ext2/3/4? msdosfs? ZFS?), so I would be careful about > >> which filesystem you pick and whether or not there's a bug where it's > >> not properly identifying that the operation you're attempting to > >> perform is valid. > >> Thanks, > >> -Garrett > >> > >> $ uname -a > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > >> Thu Aug 19 22:50:36 PDT 2010 > >> r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > Thanks, > -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
Oops =)
This version will use grep(1) if installed. Diff below.
dte...@dt.vicor.com Desktop $ diff -pub sysconf.txt{.orig,}
--- sysconf.txt.orig2010-10-06 13:50:29.0 -0700
+++ sysconf.txt 2010-10-06 13:50:45.0 -0700
@@ -349,8 +349,7 @@ depend sysconf_set 'local' 'sysconf' '['
local found=
local regex="^[[:space:]]*$varname="
for file in $conf_files; do
- #if have grep; then
- if false; then
+ if have grep; then
grep -q "$regex" $file && found=1
else
while read LINE; do \
@@ -386,8 +385,7 @@ depend sysconf_set 'local' 'sysconf' '['
( found=
while read -r LINE; do
if [ ! "$found" ]; then
- #if have grep; then
- if false; then
+ if have grep; then
match="$( echo "$LINE" | grep "$regex" )"
else
case "$LINE" in
On Wed, 2010-10-06 at 13:45 -0700, Devin Teske wrote:
> Hello fellow freebsd-hackers,
>
> Long-time hacker, first-time poster.
>
> I'd like to share a shell script that I wrote for FreeBSD system
> administration.
>
> The attached shell script works similar to sysctl(8), but rather than
> querying or working on sysctl MIBs, it instead works on the /etc/rc.conf
> (and /etc/rc.conf.local) files.
>
> Syntax shown below (available by running the script without arguments):
>
> Usage: sysconf [OPTIONS] name[=value] ...
> OPTIONS:
> -h --help Print this message to stderr and exit.
> -d Print list of internal dependencies before exit.
> -e Print query results as `var=value' (useful for producing
> output to be fed back in). Ignored if -n is specified.
> -n Show only variable values, not their names.
>
> ENVIRONMENT:
> SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one
> (default: `0')
> RC_DEFAULTS Location of `/etc/defaults/rc.conf' file.
>
> Examples:
>
> r...@mymachine ~ $ sysconf hostname
> hostname: mymachine.localdomain
> r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com
> hostname: mymachine.localdomain -> foomaster.deluex.com
> r...@mymachine ~ $ sysconf -e hostname
> hostname="foomaster.deluxe.com"
> r...@mymachine ~ $ sysconf -n hostname
> foomaster.deluxe.com
>
> The script has zero external dependencies. None. Period. It will use
> grep(1) if installed, but it is not required.
>
> Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and
> FreeBSD-8.1.
--
Cheers,
Devin Teske
-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
Hello fellow freebsd-hackers, Long-time hacker, first-time poster. I'd like to share a shell script that I wrote for FreeBSD system administration. The attached shell script works similar to sysctl(8), but rather than querying or working on sysctl MIBs, it instead works on the /etc/rc.conf (and /etc/rc.conf.local) files. Syntax shown below (available by running the script without arguments): Usage: sysconf [OPTIONS] name[=value] ... OPTIONS: -h --help Print this message to stderr and exit. -d Print list of internal dependencies before exit. -e Print query results as `var=value' (useful for producing output to be fed back in). Ignored if -n is specified. -n Show only variable values, not their names. ENVIRONMENT: SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one (default: `0') RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. Examples: r...@mymachine ~ $ sysconf hostname hostname: mymachine.localdomain r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com hostname: mymachine.localdomain -> foomaster.deluex.com r...@mymachine ~ $ sysconf -e hostname hostname="foomaster.deluxe.com" r...@mymachine ~ $ sysconf -n hostname foomaster.deluxe.com The script has zero external dependencies. None. Period. It will use grep(1) if installed, but it is not required. Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and FreeBSD-8.1. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -BEGIN GEEK CODE BLOCK- Version 3.1 GAT/CS d(+) s: a- C++() UB$ P++() L++() !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ --END GEEK CODE BLOCK-- http://www.geekcode.com/ -> END TRANSMISSION <- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On 6 October 2010 23:38, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: >> > On Wed Oct 6 10, Garrett Cooper wrote: >> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best >> >> wrote: >> >> > hi there, >> >> > >> >> > i think the following example shows the problem better than a long >> >> > explanation: >> >> > >> >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> >> > ^^non-root ^^root ^^non-root >> >> > >> >> > chflags claims to have cleared the 'arch' flag (which should be >> >> > impossible as >> >> > non-root user), but indeed has done nothing. >> >> > >> >> > i've tried the same with 'sappnd' and that works as can be expected. >> >> > >> >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, >> >> > jpaetzel) >> >> > and stable/7 (nox). >> >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with >> >> > EPERM. >> >> >> >> Fails for me when I call the syscall directly, as I would expect, >> >> and passes when I'm superuser: >> >> >> >> $ ./test_chflags >> >> (uid, euid) = (1000, 1000) >> >> test_chflags: chflags: Operation not permitted >> >> test_chflags: lchflags: Operation not permitted >> >> $ sudo ./test_chflags >> >> (uid, euid) = (0, 0) >> >> >> >> According to my basic inspection in strtofflags >> >> (.../lib/libc/gen/strtofflags.c), it works as well. >> >> And last but not least, executing the commands directly on the CLI >> >> work: >> >> >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ chflags arch $tmpfile >> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >> $ rm $tmpfile >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ sudo chflags arch $tmpfile >> >> $ sudo chflags noarch $tmpfile >> >> $ rm $tmpfile >> > >> > thanks for your test app and helping out with this problem. i'm not sure >> > however you understood the problem. probably i didn't explain it right: >> > >> > $ sudo rm -d /tmp/chflags.XX >> > $ tmpfile=`mktemp /tmp/chflags.XX` >> > $ sudo chflags arch $tmpfile >> > $ chflags noarch $tmpfile >> > >> > is what's causing the problem. the last chflags call should fail, but it >> > doesn't. >> >> Sorry... my CLI based example was stupid. I meant: >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.V2NpXR: Operation not permitted >> $ chflags noarch $tmpfile >> $ rm $tmpfile >> >> Currently chflags(2) states: >> >> The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may only >> be set or unset by the super-user. Attempts to set these flags by non- >> super-users are rejected, >>> attempts by non-superusers to clear >> flags that >> are already unset are silently ignored. <<< These flags may be set at >> any >> time, but normally may only be unset when the system is in single-user >> mode. (See init(8) for details.) >> >> So this behavior is already well documented :). The EPERM section >> should really note SF_ARCHIVED though (whoever added the flag forgot >> to add that particular item to the ERRORS section). > > that's perfectly alright. clearing an unset flag shouldn't cause any error to > be returned. however in my example arch *does* get set and still trying to > unset it as normal user doesn't return an error. > It's even more interesting. As far as I could parse the code: - UFS has no special handling for SF_ARCHIVED (I found only it for msdosfs) - ufs_setattr() does not handle unsetting SF_ARCHIVED, so all what it does is simply return zero. - /bin/chflags doesn't check the actual flags value from inode after calling chflags() syscall, and blindly assumes all is well, if chflags() returns with zero, -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Wed, Oct 6, 2010 at 1:45 PM, Devin Teske wrote: > Hello fellow freebsd-hackers, > > Long-time hacker, first-time poster. > > I'd like to share a shell script that I wrote for FreeBSD system > administration. > > The attached shell script works similar to sysctl(8), but rather than > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > (and /etc/rc.conf.local) files. > > Syntax shown below (available by running the script without arguments): > > Usage: sysconf [OPTIONS] name[=value] ... > OPTIONS: > -h --help Print this message to stderr and exit. > -d Print list of internal dependencies before exit. > -e Print query results as `var=value' (useful for producing > output to be fed back in). Ignored if -n is specified. > -n Show only variable values, not their names. > > ENVIRONMENT: > SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one > (default: `0') > RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. > > Examples: > > r...@mymachine ~ $ sysconf hostname > hostname: mymachine.localdomain > r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com > hostname: mymachine.localdomain -> foomaster.deluex.com > r...@mymachine ~ $ sysconf -e hostname > hostname="foomaster.deluxe.com" > r...@mymachine ~ $ sysconf -n hostname > foomaster.deluxe.com > > The script has zero external dependencies. None. Period. It will use > grep(1) if installed, but it is not required. > > Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and > FreeBSD-8.1. I haven't looked at this yet, but this will result in user confusion as it differs in purpose from sysconf(3) (which is a POSIX API that helps determine system configuration tunable variables)... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: > On 6 October 2010 23:38, Alexander Best wrote: >> On Wed Oct 6 10, Garrett Cooper wrote: >>> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: >>> > On Wed Oct 6 10, Garrett Cooper wrote: >>> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best >>> >> wrote: >>> >> > hi there, >>> >> > >>> >> > i think the following example shows the problem better than a long >>> >> > explanation: >>> >> > >>> >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >>> >> > ^^non-root ^^root ^^non-root >>> >> > >>> >> > chflags claims to have cleared the 'arch' flag (which should be >>> >> > impossible as >>> >> > non-root user), but indeed has done nothing. >>> >> > >>> >> > i've tried the same with 'sappnd' and that works as can be expected. >>> >> > >>> >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, >>> >> > jpaetzel) >>> >> > and stable/7 (nox). >>> >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with >>> >> > EPERM. >>> >> >>> >> Fails for me when I call the syscall directly, as I would expect, >>> >> and passes when I'm superuser: >>> >> >>> >> $ ./test_chflags >>> >> (uid, euid) = (1000, 1000) >>> >> test_chflags: chflags: Operation not permitted >>> >> test_chflags: lchflags: Operation not permitted >>> >> $ sudo ./test_chflags >>> >> (uid, euid) = (0, 0) >>> >> >>> >> According to my basic inspection in strtofflags >>> >> (.../lib/libc/gen/strtofflags.c), it works as well. >>> >> And last but not least, executing the commands directly on the CLI >>> >> work: >>> >> >>> >> $ tmpfile=`mktemp /tmp/chflags.XX` >>> >> $ chflags arch $tmpfile >>> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >>> >> $ rm $tmpfile >>> >> $ tmpfile=`mktemp /tmp/chflags.XX` >>> >> $ sudo chflags arch $tmpfile >>> >> $ sudo chflags noarch $tmpfile >>> >> $ rm $tmpfile >>> > >>> > thanks for your test app and helping out with this problem. i'm not sure >>> > however you understood the problem. probably i didn't explain it right: >>> > >>> > $ sudo rm -d /tmp/chflags.XX >>> > $ tmpfile=`mktemp /tmp/chflags.XX` >>> > $ sudo chflags arch $tmpfile >>> > $ chflags noarch $tmpfile >>> > >>> > is what's causing the problem. the last chflags call should fail, but it >>> > doesn't. >>> >>> Sorry... my CLI based example was stupid. I meant: >>> >>> $ tmpfile=`mktemp /tmp/chflags.XX` >>> $ chflags arch $tmpfile >>> chflags: /tmp/chflags.V2NpXR: Operation not permitted >>> $ chflags noarch $tmpfile >>> $ rm $tmpfile >>> >>> Currently chflags(2) states: >>> >>> The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may >>> only >>> be set or unset by the super-user. Attempts to set these flags by non- >>> super-users are rejected, >>> attempts by non-superusers to clear >>> flags that >>> are already unset are silently ignored. <<< These flags may be set at >>> any >>> time, but normally may only be unset when the system is in single-user >>> mode. (See init(8) for details.) >>> >>> So this behavior is already well documented :). The EPERM section >>> should really note SF_ARCHIVED though (whoever added the flag forgot >>> to add that particular item to the ERRORS section). >> >> that's perfectly alright. clearing an unset flag shouldn't cause any error to >> be returned. however in my example arch *does* get set and still trying to >> unset it as normal user doesn't return an error. >> > > It's even more interesting. > > As far as I could parse the code: > - UFS has no special handling for SF_ARCHIVED (I found only it for msdosfs) _very_ interesting: [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) The commit that introduced this change probably wasn't doing the right thing: http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. > - ufs_setattr() does not handle unsetting SF_ARCHIVED, > so all what it does is simply return zero. [EOPNOTSUPP] The underlying file system does not support file flags. So I would expect for invalid flags to return EOPNOTSUPP. ... $ ~/test_chflags_negative test_chflags_negative: should not get here $ sudo ~/test_chflags_negative test_chflags_negative: should not get here *facepalm* I think the problem in part is here (sys/stat.h): * * Super-user and owner changeable flags. */ #define UF_SETTABLE 0x /* mask of owner changeable flags */ #define UF_NODUMP 0x0001 /* do not dump file */ #define UF_IMMUTABLE0x0002 /* file may not be changed */ #define UF_APPEND
Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote: > Hello fellow freebsd-hackers, > > Long-time hacker, first-time poster. > > I'd like to share a shell script that I wrote for FreeBSD system > administration. > > The attached shell script works similar to sysctl(8), but rather than > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > (and /etc/rc.conf.local) files. > > Syntax shown below (available by running the script without arguments): > > Usage: sysconf [OPTIONS] name[=value] ... > OPTIONS: > -h --help Print this message to stderr and exit. > -d Print list of internal dependencies before exit. > -e Print query results as `var=value' (useful for producing > output to be fed back in). Ignored if -n is specified. > -n Show only variable values, not their names. > > ENVIRONMENT: > SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one > (default: `0') > RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. > > Examples: > > r...@mymachine ~ $ sysconf hostname > hostname: mymachine.localdomain > r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com > hostname: mymachine.localdomain -> foomaster.deluex.com > r...@mymachine ~ $ sysconf -e hostname > hostname="foomaster.deluxe.com" > r...@mymachine ~ $ sysconf -n hostname > foomaster.deluxe.com > > The script has zero external dependencies. None. Period. It will use > grep(1) if installed, but it is not required. > > Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and > FreeBSD-8.1. It seems the list ate the attachment :( Also, take a look at sysconf(3). I think there may be a certain amount of hesitation to welcome a utility with the same name as a POSIX-compliant C library function... ...how about a name like 'sysrc' or 'rcconfig' or something indicating a relationship with the rc.conf file or rc system? Anyway, sounds cool, as I've had a need recently to do some automated configuring of several rc.conf files -- my method was very hackish, and will never see the light of public scrutiny :) -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Wed, 2010-10-06 at 18:09 -0500, Brandon Gooch wrote: > On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote: > > Hello fellow freebsd-hackers, > > > > Long-time hacker, first-time poster. > > > > I'd like to share a shell script that I wrote for FreeBSD system > > administration. > > > > The attached shell script works similar to sysctl(8), but rather than > > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > > (and /etc/rc.conf.local) files. > > > > Syntax shown below (available by running the script without arguments): > > > > Usage: sysconf [OPTIONS] name[=value] ... > > OPTIONS: > >-h --help Print this message to stderr and exit. > >-d Print list of internal dependencies before exit. > >-e Print query results as `var=value' (useful for producing > >output to be fed back in). Ignored if -n is specified. > >-n Show only variable values, not their names. > > > > ENVIRONMENT: > >SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one > > (default: `0') > >RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. > > > > Examples: > > > > r...@mymachine ~ $ sysconf hostname > > hostname: mymachine.localdomain > > r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com > > hostname: mymachine.localdomain -> foomaster.deluex.com > > r...@mymachine ~ $ sysconf -e hostname > > hostname="foomaster.deluxe.com" > > r...@mymachine ~ $ sysconf -n hostname > > foomaster.deluxe.com > > > > The script has zero external dependencies. None. Period. It will use > > grep(1) if installed, but it is not required. > > > > Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and > > FreeBSD-8.1. > > It seems the list ate the attachment :( I'll post it as the body of the e-mail tomorrow (can't do it right now, just got a call from the wife -- the car broke down and I have to rush out to get her). > Also, take a look at sysconf(3). I think there may be a certain amount > of hesitation to welcome a utility with the same name as a > POSIX-compliant C library function... > > ...how about a name like 'sysrc' or 'rcconfig' or something indicating > a relationship with the rc.conf file or rc system? > > Anyway, sounds cool, as I've had a need recently to do some automated > configuring of several rc.conf files -- my method was very hackish, > and will never see the light of public scrutiny :) Thanks (to yourself and Garrett Cooper) for pointing out sysconf(3). I do agree with the possible confusion. I like the name suggestions. Let me throw out a couple more before sleeping on them tonight. rcctl (like sysctl but for rc stuffs) rcconf (pretty succinct -- too succinct?) sysrc was a great suggestion. > > -Brandon > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -BEGIN GEEK CODE BLOCK- Version 3.1 GAT/CS d(+) s: a- C++() UB$ P++() L++() !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ --END GEEK CODE BLOCK-- http://www.geekcode.com/ -> END TRANSMISSION <- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote: > On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote: >> Hello fellow freebsd-hackers, >> >> Long-time hacker, first-time poster. >> >> I'd like to share a shell script that I wrote for FreeBSD system >> administration. >> > > It seems the list ate the attachment :( Here she is ^_^ Comments welcome. #!/bin/sh # -*- tab-width: 4 -*- ;; Emacs # vi: set tabstop=4 :: Vi/ViM # # Revision: 1.0 # Last Modified: October 6th, 2010 COPYRIGHT # # (c)2010. Devin Teske. All Rights Reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright #notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions and the following disclaimer in the #documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # AUTHOR DATE DESCRIPTION # dteske 2010.09.29 Initial version. # INFORMATION # # Command Usage: # # sysrc [OPTIONS] name[=value] ... # # OPTIONS: # -h --help Print this message to stderr and exit. # -d Print list of internal dependencies before exit. # -e Print query results as `var=value' (useful for producing # output to be fed back in). Ignored if -n is specified. # -n Show only variable values, not their names. # # ENVIRONMENT: # SYSRC_SHOW_DEPS Dump list of dependencies. Must be zero or one # (default: `0') # RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. # # About the Utility: # # This utility works similar to sysctl(8). It shares the `-e' and `-n' # options (detailed above and in sysctl(8)) and also has the same # `name[=value]' syntax for querying/setting configuration options. # # Fundamentally it could be said that sysctl(8) munges sysctl MIBs in the # entrant kernel, while sysrc(8) -- this utility -- munges values in the # system rc.conf(5) configuration files. # # NOTE: System configuration files are by-default configured in the file # `/etc/defaults/rc.conf' in the variable `rc_conf_files', which by-default # contains a space-separated list of pathnames. On all FreeBSD systems, this # defaults to the value "/etc/rc.conf /etc/rc.conf.local". Each pathname is # sourced in-order upon startup. It is in the same fashion that this script # sources the configuration files before returning the value of the given # variable by-name. # # When you supply this utility with a variable name, it will return the value # of the variable. If the variable does not appear in any of the configured # rc_conf_files, an error is printed and we return with error status. # # When changing values of a given variable it does not matter if the variable # appears in any of the rc_conf_files or not. If the variable does not appear # in any of the files, it is appended to the end of the first pathname in the # rc_conf_files variable. Otherwise, the sysrc_set() function will replace # only the last-occurrence in the last-file found to contain the variable. # This effectively gets the value to take effect next reboot without heavily # modifying these integral files (yet taking care not to allow the file to # grow unweildy should the script be called repeatedly infinitum). # # About the Code: # # I hope that you enjoy the cleanliness, verbosity (but at the same time, # utilitarian brevity) and -- dare I say -- beauty of the code of this # utility. I have been refining my cross-platform/POSIX-compliant/baseline- # compatible method of pure-bourne shell scripting for 10 years now. Shell is # not the only language that I could have chosen to written this utility in, # but it assuredly was the most satisfying. Satisfying in the sense that such # a utility is infinitely more useful to the masses if programmed in the # ba
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Oct 6, 2010, at 8:29 PM, Devin Teske wrote:
>
> On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
>
>> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
>>> Hello fellow freebsd-hackers,
>>>
>>> Long-time hacker, first-time poster.
>>>
>>> I'd like to share a shell script that I wrote for FreeBSD system
>>> administration.
>>>
>>
>> It seems the list ate the attachment :(
>
>
> Here she is ^_^ Comments welcome.
>
Again with the patch needed... :(
Was testing embedded environment sans-grep(1).
dte...@dt.vicor.com bin $ diff -pu sysrc{.orig,}
--- sysrc.orig 2010-10-06 20:47:55.0 -0700
+++ sysrc 2010-10-06 20:48:06.0 -0700
@@ -492,8 +492,7 @@ depend sysrc_set 'local' 'sysrc' '[' 're
local found=
local regex="^[[:space:]]*$varname="
for file in $conf_files; do
- #if have grep; then
- if false; then
+ if have grep; then
grep -q "$regex" $file && found=1
else
while read LINE; do \
@@ -529,8 +528,7 @@ depend sysrc_set 'local' 'sysrc' '[' 're
( found=
while read -r LINE; do
if [ ! "$found" ]; then
- #if have grep; then
- if false; then
+ if have grep; then
match="$( echo "$LINE" | grep "$regex" )"
else
case "$LINE" in
> #!/bin/sh
> # -*- tab-width: 4 -*- ;; Emacs
> # vi: set tabstop=4 :: Vi/ViM
> #
> # Revision: 1.0
> # Last Modified: October 6th, 2010
> COPYRIGHT
> #
> # (c)2010. Devin Teske. All Rights Reserved.
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions
> # are met:
> # 1. Redistributions of source code must retain the above copyright
> #notice, this list of conditions and the following disclaimer.
> # 2. Redistributions in binary form must reproduce the above copyright
> #notice, this list of conditions and the following disclaimer in the
> #documentation and/or other materials provided with the distribution.
> #
> # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO, THE
> # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> # SUCH DAMAGE.
> #
> # AUTHOR DATE DESCRIPTION
> # dteske 2010.09.29 Initial version.
> #
> INFORMATION
> #
> # Command Usage:
> #
> # sysrc [OPTIONS] name[=value] ...
> #
> # OPTIONS:
> # -h --help Print this message to stderr and exit.
> # -d Print list of internal dependencies before exit.
> # -e Print query results as `var=value' (useful for producing
> # output to be fed back in). Ignored if -n is specified.
> # -n Show only variable values, not their names.
> #
> # ENVIRONMENT:
> # SYSRC_SHOW_DEPS Dump list of dependencies. Must be zero or one
> # (default: `0')
> # RC_DEFAULTS Location of `/etc/defaults/rc.conf' file.
> #
> # About the Utility:
> #
> # This utility works similar to sysctl(8). It shares the `-e' and `-n'
> # options (detailed above and in sysctl(8)) and also has the same
> # `name[=value]' syntax for querying/setting configuration options.
> #
> # Fundamentally it could be said that sysctl(8) munges sysctl MIBs in the
> # entrant kernel, while sysrc(8) -- this utility -- munges values in the
> # system rc.conf(5) configuration files.
> #
> # NOTE: System configuration files are by-default configured in the file
> # `/etc/defaults/rc.conf' in the variable `rc_conf_files', which by-default
> # contains a space-separated list of pathnames. On all FreeBSD systems, this
> # defaults to the value "/etc/rc.conf /etc/rc.conf.local". Each pathname is
> # sourced in-order upon startup. It is in the same fashion that this script
> # sources the configuration files before returning the value of the given
> # variable by-name.
> #
> # When you supply this utility with a variable name, it will return the
> value
> # of the variable. If the variable does not appear in any of the configured
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On 10/06/2010 23:29, Devin Teske wrote: I am not saying this to sound like I am shooting down this script but from the looks of it, I see no real advantage over the way a FreeBSD system is configured already. You could probably point these out though. With that noted what advantage does this script bring compared to a script like service(8) that is already in the base system? How much time does a end user spend enabling/disabling services for a system? How much of a difference in time would this make to the end user as per say just having to echo a variable into an rc.conf? If this would be put in place into the base system where would it be and who would maintain it ? Is it feasible to expect an end user to read rc.conf(5) services(8) while also consuming knowledge of etc/defaults/rc.conf & boot(8) as well sysctl.conf(5) and loader.conf(5). Also you search for grep and awk in your script. If this were to be in base, then utilities like this would not need to be searched for as base utilities are generally static to where they live in the file-system already... /usr/bin/grep /usr/bin/awk for example. I do not think it makes much sense for a base utility to search outside of its world for a executable especially for grep(1) and awk(1). Call these directly and let the end user modify their PATH as to where the location of these would actually be called from rather than adding extra complicity. > -> LEGAL DISCLAIMER <- > This message contains confidential and proprietary information > of the sender, and is intended only for the person(s) to whom it > is addressed. Any use, distribution, copying or disclosure by any > other person is strictly prohibited. If you have received this > message in error, please notify the e-mail sender immediately, > and delete the original message without making a copy. Due to this disclaimer I am not sure that even the implicit BSD license can override this. Though there is a thin gray line here, it might be suitable to remove this from future email unless you are specifically addressing something to a specific person. Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: >> On 6 October 2010 23:38, Alexander Best wrote: >>> On Wed Oct 6 10, Garrett Cooper wrote: On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best >> wrote: >> > hi there, >> > >> > i think the following example shows the problem better than a long >> > explanation: >> > >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> > ^^non-root ^^root ^^non-root >> > >> > chflags claims to have cleared the 'arch' flag (which should be >> > impossible as >> > non-root user), but indeed has done nothing. >> > >> > i've tried the same with 'sappnd' and that works as can be expected. >> > >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, >> > jpaetzel) >> > and stable/7 (nox). >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails with >> > EPERM. >> >> Fails for me when I call the syscall directly, as I would expect, >> and passes when I'm superuser: >> >> $ ./test_chflags >> (uid, euid) = (1000, 1000) >> test_chflags: chflags: Operation not permitted >> test_chflags: lchflags: Operation not permitted >> $ sudo ./test_chflags >> (uid, euid) = (0, 0) >> >> According to my basic inspection in strtofflags >> (.../lib/libc/gen/strtofflags.c), it works as well. >> And last but not least, executing the commands directly on the CLI >> work: >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> $ rm $tmpfile >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ sudo chflags arch $tmpfile >> $ sudo chflags noarch $tmpfile >> $ rm $tmpfile > > thanks for your test app and helping out with this problem. i'm not sure > however you understood the problem. probably i didn't explain it right: > > $ sudo rm -d /tmp/chflags.XX > $ tmpfile=`mktemp /tmp/chflags.XX` > $ sudo chflags arch $tmpfile > $ chflags noarch $tmpfile > > is what's causing the problem. the last chflags call should fail, but it > doesn't. Sorry... my CLI based example was stupid. I meant: $ tmpfile=`mktemp /tmp/chflags.XX` $ chflags arch $tmpfile chflags: /tmp/chflags.V2NpXR: Operation not permitted $ chflags noarch $tmpfile $ rm $tmpfile Currently chflags(2) states: The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may only be set or unset by the super-user. Attempts to set these flags by non- super-users are rejected, >>> attempts by non-superusers to clear flags that are already unset are silently ignored. <<< These flags may be set at any time, but normally may only be unset when the system is in single-user mode. (See init(8) for details.) So this behavior is already well documented :). The EPERM section should really note SF_ARCHIVED though (whoever added the flag forgot to add that particular item to the ERRORS section). >>> >>> that's perfectly alright. clearing an unset flag shouldn't cause any error >>> to >>> be returned. however in my example arch *does* get set and still trying to >>> unset it as normal user doesn't return an error. >>> >> >> It's even more interesting. >> >> As far as I could parse the code: >> - UFS has no special handling for SF_ARCHIVED (I found only it for msdosfs) > > _very_ interesting: > > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn > fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) > > The commit that introduced this change probably wasn't doing the > right thing: > http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. > >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, >> so all what it does is simply return zero. > > [EOPNOTSUPP] The underlying file system does not support file > flags. > > So I would expect for invalid flags to return EOPNOTSUPP. > > ... > > $ ~/test_chflags_negative > test_chflags_negative: should not get here > $ sudo ~/test_chflags_negative > test_chflags_negative: should not get here > > *facepalm* > > I think the problem in part is here (sys/stat.h): > > * > * Super-user and owner changeable flags. > */ > #define
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Oct 6, 2010, at 9:49 PM, jhell wrote: > On 10/06/2010 23:29, Devin Teske wrote: > > I see no real advantage If you had to administer thousands of FreeBSD systems, you would. This script is obviously targeted to those for which are mentioned in the header... "system administrators, power-users, and developers". > With that noted what advantage does this script bring compared to a > script like service(8) that is already in the base system? service(8) clearly doesn't do what this script does. The values that associate to an executable rc.d script are but only a fraction of what rc.conf(5) is used for. See `/etc/defaults/rc.conf' for all possible values. > How much time does a end user spend enabling/disabling services for a > system? In our environment? A script like this empowers support personnel and engineers with the ability to perform a generalized query on thousands of machines simultaneously and collate the results back into a paging application (such as less(1) or more(1)), finding possible misconfigurations, problems, or other issues that arise by human error, script error, or legacy options languishing from an upgrade process. Further, with the ability to set options, it makes remediating problems quite easy. > How much of a difference in time would this make to the end user as per > say just having to echo a variable into an rc.conf? That's a sloppy way to manage production equipment/environments. > If this would be put in place into the base system where would it be and > who would maintain it ? It would likely be placed in the same directory as sysctl(8) (/sbin/sysrc). I would maintain it. > Is it feasible to expect an end user to read rc.conf(5) services(8) > while also consuming knowledge of etc/defaults/rc.conf & boot(8) as well > sysctl.conf(5) and loader.conf(5). A friend of mine and I just installed 8.1-RELEASE-p1 onto his laptop. We had to go through all those man-pages and more to get everything good with the wpa_supplicant_* options. We didn't have to go to google, bing, wolfram alpha, barnes & noble, or any place... all the answers for setting up his laptop using 802.11g tied to a WAP w/ WPA2. But what does that have to do with the price of bread in China? This script helps system administrators, power-users, and developers. It's designed to make the task of performing non-interactive edits to rc.conf(5) not only easier, but cleaner. The files are left fully in-tact by the script, which is the important part to note. It's not going to sloppily keep tacking on new values for the same directive if the script is called 1,000 times over. This enables such things as being called from cron on a regular basis even. > Also you search for grep and awk in your script. No. I check for the presence of them with $PATH expansion. The have() function is a one-line function that remaps the `type' shell built-in to have no output, yet still return the error status (or lack thereof). If you read the sh(1) manual, you'll see that the `type' built-in can be passed a shell keyword, a shell function, or failing that, it will find the executable via $PATH expansion, and failing that will return error status. The have() function that I have defined in my script allows me to do this: if have grep; then # use grep else # use case with glob(7) pattern matching fi > If this were to be in > base, then utilities like this would not need to be searched for as base > utilities are generally static to where they live in the file-system > already... /usr/bin/grep /usr/bin/awk for example. I do not think it > makes much sense for a base utility to search outside of its world for a > executable especially for grep(1) and awk(1). Call these directly and > let the end user modify their PATH as to where the location of these > would actually be called from rather than adding extra complicity. The integral point of confusion is lack of knowledge that have() is `type' which already performs $PATH expansion. I'm not probing for their location, I'm testing for their existence so that I can use the name. Think of it like a `try' statement. >> -> LEGAL DISCLAIMER <- >> This message contains confidential and proprietary information >> of the sender, and is intended only for the person(s) to whom it >> is addressed. Any use, distribution, copying or disclosure by any >> other person is strictly prohibited. If you have received this >> message in error, please notify the e-mail sender immediately, >> and delete the original message without making a copy. > Due to this disclaimer I am not sure that even the implicit BSD license > can override this. Though there is a thin gray line here, it might be > suitable to remove this from future email unless you are specifically > addressing something to a specific person. Please. If you read it (as have I many times) it means nothing more than that I own the IP rights to what I wrote and that if you ar
